 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| galileo GT-96100A advanced communication controller datasheet revision 1.0 3 october, 2000 f eatures www.galileot.com support@galileot.com please contact galileo technology for possible updates before finalizing a design. ? integrated communication controller and system controller with pci interface for high- performance embedded control applications. ? eight multi-protocol serial controllers (mpscs): - support hdlc, bisync, uart and transparent protocols. - bit rate of up to 55mbit/s on multiple channels simultaneously. - can drive dedicated pins or use tdms. - dedicated dpll for clock recovery and data encoding/decoding. - supports nrz, nrzi, fm0, fm1, manchester and differential manchester. - hardware support for hdlc over asynchronous channel in uart mode. ? four flextdm channels: - time slot assigner for serial and control channels. - supports up to four basic rate isdn interfaces (2b+d) in gci mode. - fully programmable via dual-port memory. ? two 10/100mbps fast ethernet mac controllers: - mii/rmii interface. - full duplex and flow-control support. - programmable perfect filtering of 1/2k or 8k mac addresses (both physical and multicast). - 2 queues for tx priority queueing - 4 queues for priority queuing based on ip dscp field or 802.1q tag or mac address. - igmp and bpdu packet trapping. ? twenty serial dma (sdma) channels to support the communications and ethernet controllers. - moves data between communications controllers and sdram/pci. - buffer chaining via a linked list of descriptors. ? eight baud rate generators with multiple clock sources. ? 64-bit cpu bus interface: - supports all 64-bit bus mips cpus: rm5260, rm5270/1 and rm7000 from qed, rv4600 through rv5000 from idt and r5000 compatibles from various vendors. - 100mhz bus frequency. - 3.3v bus interface. - support for multiple GT-96100A devices on the same sysad bus (up to 4). - 8x64-bit (64 byte) cpu write posting buffer accepts cpu writes with zero wait-states. - cpu address remapping to resources. - zero wait state secondary cache support (l2 of r4xxx and r5000, l3 of r7000). - backward software compatibility with gt-64010a, gt-64011 and gt-64120.
GT-96100A advanced communication controller 2 revision 1.0 ? sdram controller: - 3.3v (5v tolerant). - 4gb address space. - supports 16/64/128/256/512mbit sdram devices. - supports 64-bit registered sdram. - supports 2-way & 4-way sdram bank interleaving. - up to 4gb bank address space, 1mb granularity. - 1 to 4 banks supported. - 64-bit data width. - ecc support for 64-bit sdram. - zero wait-state interleaved burst accesses at 100mhz. - supports the vesa unified memory architecture (vuma) standard - allows for external masters access to sdram directly. ? device controller: - 5 chip selects. - programmable timing for each chip select. - supports many types of standard memory and i/o devices. - up to 4gb address space. - optional external wait-state support. - 8-,16-,32- and 64-bit width device support. - support for boot roms. ? four independent dma (idma) channels: - chaining via linked-lists of records. - byte address boundary for source and destination. - moves data between pci, memory, and devices. - two 64-byte internal fifos. - alignment of source and destination addresses. - dmas can be initiated by the cpu writing to a register, external request via dmareq* pin, or an internal timer/ counter. - termination of dma transfer on each channel. - descriptor ownership transfer to cpu. - fly-by support for local data bus. - override capability of source/ destination/record address mapping. GT-96100A advanced communication controller revision 1.0 3 ? two 32-bit or one 64-bit high-performance pci 2.1 compliant devices: - dual mode pci interface can be used as two independent 32-bit interfaces (synchronous or asynchronous to each other) or as a single 64-bit interface. - 192-bytes of posted write and read prefetch buffers for each pci interface. - 32/64-bit pci master and target operations. - pci bus speed of up to 66mhz with zero wait states. - universal pci buffers (each 32-bit pci use a different voltage). - operates either synchronous or asynchronous to the cpu clock. - burst transfers used for efficient data movement. - doorbell interrupts provided between cpu and pci. - supports flexible byte swapping through pci interface. - synchronization barrier support for pci side. - pci address remapping to resources. ? host to pci bridge: - translates cpu cycles into pci i/o or memory cycles. - generates pci configuration, interrupt acknowledge, and special cycles on pci bus. ? pci to main memory bridge: - supports fast back-to-back transactions. - supports memory and i/o transactions to internal configuration registers. - supports locked operations. ? i 2 o and plug and play support: - industry standard i 2 o messaging unit on primary 32-bit pci interface (also available in 64-bit mode). - plug and play compatible configuration registers. - pci configuration header can be loaded from boot prom. - pci configuration registers are accessible from both cpu and pci bus. - expansion rom support. ? pci hot-plug and compactpci hot-swap capable compliant. ? two programmable pci arbiter functions: - supports up to 9 external agents in addition to pci_0 and pci_1 internal devices. - two level priority arbitration capability - each request can be assigned either high or low priority. ? two-stage watchdog timer (nmi, reset). ? one 32-bit wide timer/counter, three 24-bit wide timer/counters. ? eighty-eight pins dedicated for peripheral functions and general purpose i/os. - each pin can be configured independently as peripheral or general purpose i/o. - supports simple i/o and led control. - inputs can generate a maskable interrupt. ? 2.5v core supply voltage, 3.3v i/o supply voltage (pci and peripherals). - all inputs are 5v tolerant. ? jtag boundary scan. ? 492 pin pbga package. ? advanced 0.25 micron cmos process. GT-96100A advanced communication controller 4 revision 1.0 part number: GT-96100A publication revision: 1.0 ? galileo technology, inc. no part of this datasheet may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of galileo technology, inc. galileo technology, inc. retains the right to make changes to these specifications at any time, without notice. galileo technology, inc. makes no warranty of any kind, expressed or implied, with regard to this material, including, but not limited to, the implied warranties of merchant- ability or fitness for any particular purpose. galileo technology, inc. further does not war- rant the accuracy or completeness of the information, text, graphics, or other items contained within these materials. galileo technology, inc. makes no commitment to update nor to keep current the information contained in this document. galileo technology, inc. assumes no responsibility for the use of any circuitry other than circuitry embodied in galileo technology, inc. products. no other circuit patent licenses are implied. galileo technology, inc. products are not designed for use in life support equipment or applications in which if the product failed it would cause a life threatening situation. do not use galileo technology, inc. products in these types of equipment or applications. contact your local sales office to obtain the latest specifications before finalizing your product. galileo technology, inc. 142 charcot avenue san jose, california 95131 phone: 1 408 367-1400 fax: 1 (408) 367-1401 e-mail: info@galileot.com www.galileot.com other brands and names are the property of their respective owners. GT-96100A advanced communication controller revision 1.0 5 t able of c ontents 1. overview ..................................................................................................................... 19 1.1 communication unit description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2 cpu interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.3 sdram and device interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4 pci interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.5 independent dma (idma) engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.6 peripheral configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2. pin information........................................................................................................... 25 3. address space decoding.......................................................................................... 56 3.1 two stage decoding process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.2 disabling address decoders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.3 dma unit address decoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.4 address space decoding errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.5 default memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.6 address remapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.7 using the cpu pci override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.8 using the dma to pci bypass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4. cpu interface description......................................................................................... 72 4.1 cpu interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 4.2 sysad, sysadc, and syscmd buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3 operation of wrrdy* and the internal write posting queues . . . . . . . . . . . . . . . . . . . . . 79 4.4 cpu write modes and write patterns supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.5 cpu interface endianess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.6 burst order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.7 mips l2 cache support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.8 multiple GT-96100A support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.9 cpu interface restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.10 cpu interface control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5. memory controller ..................................................................................................... 95 5.1 sdram controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.2 connecting the address bus to the sdram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.3 programmable sdram parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.4 sdram performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.5 sdram bank interleaving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.6 unified memory architecture (uma) support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7 device controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.8 programming the adp lines for other functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.9 memory controller restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.10 registered sdram interface restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.11 memory interface control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6. data integrity ............................................................................................................ 143 6.1 sdram ecc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 43 6.2 pci parity support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 GT-96100A advanced communication processor 6 revision 1.0 6.3 parity support for devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 6.4 cpu parity support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7 6.5 data integrity flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.6 register information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 50 6.7 cpu errors report registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 7. pci interfaces ........................................................................................................... 152 7.1 reset configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 52 7.2 pci master operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 7.3 pci target interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 57 7.4 pci synchronization barriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 7.5 pci master configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.6 target configuration and plug and play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.7 pci bus/device bus/cpu clock synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 7.8 64-bit pci configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 7.9 retry enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 7.10 locked cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 7.11 hot-swap support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 68 7.12 pci power management support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 7.13 pci interface restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9 7.14 pci control and configuration registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8. intelligent i/o (i2o) standard support .................................................................... 201 8.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 8.2 i2o registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 8.3 enabling i2o support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8.4 register map compatibility with the i960rx family . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8.5 message registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3 8.6 doorbell registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 8.7 circular queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 8.8 i2o support registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9. independent dma controllers (idma controllers)................................................ 219 9.1 dma channel registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 9.2 dma channel control register (0x840 - 0x84c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 9.3 restarting a disabled channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 9.4 reprogramming an active channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 9.5 arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 9.6 current descriptor pointer registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 9.7 design information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 25 9.8 initiating a dma from a timer/counter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 9.9 dma restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 9.10 dma control registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 10. pci arbiter ................................................................................................................ 2 41 10.1 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 10.2 arbitration scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 10.3 arbitration parking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 10.4 pci arbiter configuration register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 GT-96100A advanced communication controller revision 1.0 7 11. communication interface unit (ciu) ...................................................................... 246 11.1 ciu connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 11.2 address decoding and pci override (master) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 11.3 arbitration scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 11.4 ciu arbiter configuration register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 12. 10/100mb ethernet unit ........................................................................................... 253 12.1 functional overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 12.2 port features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 12.3 operational description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5 12.4 ethernet port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 12.5 internal control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3 12.6 ethernet mib counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 13. serial dma (sdma) .................................................................................................. 307 13.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 13.2 sdma descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 08 13.3 sdma configuration register (sdc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 13.4 sdma command register (sdcmx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 13.5 sdma group configuration register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 13.6 sdma descriptor pointer registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 13.7 transmit sdma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 13.8 receive sdma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 13.9 sdma interrupt and mask register (sdi and sdm). . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 13.10 sdma in auto mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9 13.11 sdma registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 14. multi protocol serial controller (mpsc) ................................................................ 326 14.1 dpll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 14.2 mpscx main configuration register (mmcrx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 14.3 mpscx protocol configuration registers (mpcrx) . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 14.4 channel registers (chxrx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 14.5 hdlc mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 14.6 bisync mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 14.7 uart mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 14.8 transparent protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 15. flextdm units (ftdm)............................................................................................. 379 15.1 flextdm architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 0 15.2 flextdm dpram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 15.3 flextdm programing modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 15.4 flextdm configuration register (tcr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 15.5 flextdm synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 15.6 iom (gci) mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 15.7 pcm highway mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 15.8 data rate adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 88 15.9 flextdm auxiliary channels a and b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 15.10 iom programing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 15.11 flextdm registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 GT-96100A advanced communication processor 8 revision 1.0 16. baud rate generators (brgs) ................................................................................ 397 16.1 brg inputs and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 16.2 brg baud tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7 16.3 brg registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398 17. watchdog timer ....................................................................................................... 401 17.1 watchdog registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 1 17.2 watchdog operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 18. timers/counters....................................................................................................... 403 18.1 timer / counter registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 19. general purpose ports ............................................................................................ 405 19.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 19.2 general purpose control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 20. physical signal routing .......................................................................................... 414 20.1 signal routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 20.2 clock routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 21. interrupt controller .................................................................................................. 424 21.1 interrupt cause registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 21.2 interrupt mask registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 21.3 interrupt summaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 26 21.4 interrupt select registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6 21.5 interrupt registers tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 22. reset configuration ................................................................................................. 452 23. connecting the memory controller to sdram and devices................................ 455 23.1 sdram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 23.2 devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 24. jtag interface.......................................................................................................... 460 24.1 ieee standard 1149.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 24.2 tap controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 24.3 instruction register (ir) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 24.4 bypass register (br). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 1 24.5 jtag scan chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 24.6 id register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 25. big and little endian ............................................................................................... 463 25.1 background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 25.2 configuring a system for big and little endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 26. using the gt?96100a without the cpu interface ................................................. 466 27. using the gt?96100a in different pci configurations......................................... 467 28. phased locked loop (pll) application notes ..................................................... 473 28.1 pll power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 28.2 pll characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 GT-96100A advanced communication controller revision 1.0 9 29. system configurations............................................................................................ 475 29.1 minimal system configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 29.2 typical system configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 29.3 high performance system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 30. register tables ........................................................................................................ 478 30.1 access to on-chip pci configuration space registers . . . . . . . . . . . . . . . . . . . . . . . . 478 30.2 register maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 31. dc characteristics ................................................................................................... 508 31.1 dc electrical characteristics over operating range . . . . . . . . . . . . . . . . . . . . . . . . . . 509 31.2 thermal data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512 32. ac timing ................................................................................................................. 51 3 32.1 tclk/pclk restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 16 32.2 serial (communication) clock domain ac characteristic . . . . . . . . . . . . . . . . . . . . . . 518 32.3 mpsc waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 32.4 mii waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 32.5 jtag ac characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 32.6 additional delay due to capacitive loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531 33. pinout table, 492 pin bga ...................................................................................... 533 34. 492 bga package mechanical information ........................................................... 542 35. gt?96100a part numbering.................................................................................... 543 35.1 standard part number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 35.2 valid part numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 43 36. abbreviations ........................................................................................................... 544 37. revision history....................................................................................................... 545 GT-96100A advanced communication controller 10 revision 1.0 list of tables 1. overview ..................................................................................................................... 19 table 1: gt?96100a serial performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 table 2: gt?96100a port configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 table 3: gt?96100a peripheral configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2. pin information ........................................................................................................... 25 table 4: cpu interface pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 table 5: secondary cache interface pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . 26 table 6: pci bus 0 pin assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 table 7: pci bus 1 pin assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 table 8: sdram and devices pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 table 9: local address and data bus pin assignments . . . . . . . . . . . . . . . . . . . . . . . . 32 table 10: dma pin assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 table 11: wan pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 table 12: lan pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 table 13: gpp pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 table 14: interrupt interface pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 table 15: watchdog interface pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 table 16: test interface pin assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 table 17: clock/control interface pin assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3. address space decoding .......................................................................................... 56 table 18: cpu and device decoder mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 table 19: pci_0 base address register and device decoder mappings. . . . . . . . . . . . 58 table 20: pci_1 base address register and device decoder mappings. . . . . . . . . . . . 58 table 21: cpu and device decoder default address mapping . . . . . . . . . . . . . . . . . . . 64 table 22: pci function 0 and device decoder default address mapping . . . . . . . . . . . 65 table 23: pci function 1 (byte order swap) and device decoder default address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 table 24: pci address remapping example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4. cpu interface description ......................................................................................... 72 table 25: cpu interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 table 26: syscmd bit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 table 27: address phase syscmd[8:0] encodings (driven by cpu) . . . . . . . . . . . . . . . 74 table 28: read response syscmd[8:0] encodings (driven by the GT-96100A) . . . . . . 75 table 29: cpu write syscmd[8:0] encodings (driven by local master) . . . . . . . . . . . . . 76 table 30: sysad read phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 table 31: sysad write phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 table 32: pin strapping the GT-96100A id. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 table 33: wrrdy*, validin*, and scdoe* signal multiple GT-96100A functionality . . . 82 table 34: initializing a multiple GT-96100A system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 table 35: cpu interface register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5. memory controller ..................................................................................................... 95 table 71: dmareq*, ready* and bypsoe* functionality . . . . . . . . . . . . . . . . . . . . . . . 101 GT-96100A advanced communication controller revision 1.0 11 table 72: sysad/pci address decoding for 32-bit sdram, 16 mbit . . . . . . . . . . . . . 104 table 73: sysad/pci address decoding for 64-bit sdram, 256/512 mbit . . . . . . . . . 104 table 74: sysad/pci address decoding for 32-bit sdram, 64 mbit . . . . . . . . . . . . . 105 table 75: sysad/pci address decoding for 64-bit sdram, 64/128 mbit . . . . . . . . . . 105 table 76: sysad/pci address decoding for 64-bit sdram, 256 mbit . . . . . . . . . . . . 106 table 77: programmable sdram parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 table 78: cpu sdram performance on reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 table 79: events determining pci read performance from sdram . . . . . . . . . . . . . 111 table 80: gt?96100a sync. modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 table 81: sdram performance summary pci read accesses . . . . . . . . . . . . . . . . . 112 table 82: uma ac timing parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 table 83: adp[7:0] pin functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 table 84: 32-bit device limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 table 85: memory interface register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6. data integrity ............................................................................................................ 143 table 123: ecc code matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 table 124: registers for implementing parity and ecc . . . . . . . . . . . . . . . . . . . . . . . . . 150 7. pci interfaces ........................................................................................................... 152 table 130: devnum to idsel mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 table 131: pci_0 registers loaded at reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 table 132: pci_1 registers loaded at reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 table 133: pci control and configuration register map . . . . . . . . . . . . . . . . . . . . . . . . 169 8. intelligent i/o (i2o) standard support.................................................................... 201 table 209: i2o pci and cpu offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 table 210: register differences between the gt?96100a and i960rx. . . . . . . . . . . . . 203 table 211: circular queue starting addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 table 212: i2o circular queue functional summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 209 table 213: i2o support register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9. independent dma controllers (idma controllers)................................................ 219 table 237: location of source address, slp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 table 238: location of destination address, dlp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 table 239: location of record address, rlp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 table 240: idma controller design information terms and definitions . . . . . . . . . . . . . 225 table 241: source and data transfer examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 table 242: fly-by bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 table 243: dma control register map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 10. pci arbiter ................................................................................................................ 2 41 table 269: pci arbiter?s interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 11. communication interface unit (ciu) ...................................................................... 246 12. 10/100mb ethernet unit ........................................................................................... 253 table 273: ethernet tx descriptor - command/status word . . . . . . . . . . . . . . . . . . . . . 260 table 274: ethernet tx descriptor - byte count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 GT-96100A advanced communication controller 12 revision 1.0 table 275: ethernet tx descriptor - buffer pointer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 table 276: ethernet tx descriptor - next descriptor pointer . . . . . . . . . . . . . . . . . . . . . 261 table 277: ethernet rx descriptor - command/status word . . . . . . . . . . . . . . . . . . . . . 264 table 278: ethernet rx descriptor - buffer size / byte count . . . . . . . . . . . . . . . . . . . . 266 table 279: ethernet rx descriptor - buffer pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 table 280: ethernet rx descriptor - next descriptor pointer . . . . . . . . . . . . . . . . . . . . . 266 table 281: hash table entry fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 table 282: packet filtering status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 table 283: mii management frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 table 284: bit transmission parts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 table 285: ethernet unit register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 table 300: ip differentiated services codepoint to priority0 low (dscp2p0l) . . . . . . . 299 table 301: ip differentiated services codepoint to priority0 high (dscp2p0h) . . . . . . 299 table 302: ip differentiated services codepoint to priority1 low (dscp2p1l) . . . . . . . 299 table 303: ip differentiated services codepoint to priority1 high (dscp2p1h) . . . . . . 299 table 304: vlan priority tag to priority (vpt2p). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 table 305: writing ip dscp priority example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 table 306: writing vlan priority example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 table 307: writing ip dscp and vlan priority example . . . . . . . . . . . . . . . . . . . . . . . . 301 table 308: writing ip dscp and vlan priority register mapping example . . . . . . . . . 301 table 309: terms used in mib counters descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 301 13. serial dma (sdma) .................................................................................................. 307 table 311: sdma descriptor - command/status word . . . . . . . . . . . . . . . . . . . . . . . . . . 309 table 312: sdma descriptor - buffer size, byte count (rx descriptor) . . . . . . . . . . . . . 310 table 313: sdma descriptor - byte count, shadow byte count (tx descriptor) . . . . . . 310 table 314: sdma descriptor - buffer pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 table 315: sdma descriptor - next descriptor pointer . . . . . . . . . . . . . . . . . . . . . . . . . 311 table 319: sdma definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 table 320: sdma group 0 register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 table 321: sdma group 1 register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 14. multi protocol serial controller (mpsc)................................................................. 326 table 323: tidl/rtsm relationship. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 table 325: sdmax command/status field for hdlc mode. . . . . . . . . . . . . . . . . . . . . . 338 table 337: bisync receiver operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 table 338: sdmax command/status field for bisync mode . . . . . . . . . . . . . . . . . . . . 350 table 341: bisync control character register format . . . . . . . . . . . . . . . . . . . . . . . . . 358 table 342: auto transparent programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 table 343: cpu controlled operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 table 345: sdmax command/status field for uart mode. . . . . . . . . . . . . . . . . . . . . . 362 table 347: uart stop bit reception and framing error . . . . . . . . . . . . . . . . . . . . . . . . 365 table 349: uart control character register format. . . . . . . . . . . . . . . . . . . . . . . . . . . 371 table 351: sdmax command/status field for transparent mode . . . . . . . . . . . . . . . . . 374 table 352: transparent mode synchronization options . . . . . . . . . . . . . . . . . . . . . . . . . 376 table 353: transmitter mode synchronization options . . . . . . . . . . . . . . . . . . . . . . . . . 376 GT-96100A advanced communication controller revision 1.0 13 15. flextdm units (ftdm)............................................................................................. 379 table 356: flex tdm dpram entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 table 358: monitor channel handshaking process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 table 359: iom-1 programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 table 360: iom2-te programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 table 361: iom2-lc (connected to channel 3) gci . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 table 362: flextdm register map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 16. baud rate generators (brgs)................................................................................ 397 table 363: brg registers map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 table 364: brgx configuration register (bcr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 table 365: brgx baud tuning register (btr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 17. watchdog timer ....................................................................................................... 401 18. timers/counters....................................................................................................... 403 19. general purpose ports ............................................................................................ 405 table 373: control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 table 374: gpp registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 20. physical signal routing .......................................................................................... 414 21. interrupt controller .................................................................................................. 424 table 390: interrupt registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 22. reset configuration................................................................................................. 452 table 420: reset configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 23. connecting the memory controller to sdram and devices ............................... 455 table 421: 64-bit sdram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 table 422: 32-bit sdram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 table 423: 64-bit devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 table 424: 32-bit devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 table 425: 16-bit devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 table 426: 8-bit devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 24. jtag interface.......................................................................................................... 460 table 427: supported jtag instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 table 428: idcode register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 25. big and little endian ............................................................................................... 463 table 429: nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 table 430: configuring for big and little endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 26. using the gt?96100a without the cpu interface................................................. 466 table 431: cpu-less pin strapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 27. using the gt?96100a in different pci configurations......................................... 467 table 432: no pci interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 table 433: pci_0 as 32-bit pci only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 table 434: pci_0 as 32-bit pci and pci_1 as 32-bit pci . . . . . . . . . . . . . . . . . . . . . . . 470 GT-96100A advanced communication controller 14 revision 1.0 table 435: pci_0 as 64-bit pci only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 28. phased locked loop (pll) application notes ..................................................... 473 29. system configurations ............................................................................................ 475 30. register tables ........................................................................................................ 478 table 436: cpu registers map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 table 437: sdram registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 table 438: dma registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 table 439: timer/counter registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 table 440: pci registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 table 441: interrupts registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 table 442: i2o support registers map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 table 443: communication unit register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 31. dc characteristics ................................................................................................... 508 table 444: absolute maximum ratings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 table 445: recommended operating conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 table 446: pin capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 table 447: dc electrical characteristics over operating range . . . . . . . . . . . . . . . . . . 509 table 448: driving pad characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 table 449: thermal data for GT-96100A in bga 492 . . . . . . . . . . . . . . . . . . . . . . . . . . . 512 32. ac timing ................................................................................................................. 51 3 table 450: ac timing measurement formulas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 table 451: ac commercial grade timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 table 452: tclk/pclk restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 table 453: flex-tdm receive timing - normal clock . . . . . . . . . . . . . . . . . . . . . . . . . . 518 table 454: flex-tdm transmit timing - normal speed clock . . . . . . . . . . . . . . . . . . . . 519 table 455: flex-tdm receive timing - double speed clock . . . . . . . . . . . . . . . . . . . . . 520 table 456: flex-tdm transmit timing - double speed clock . . . . . . . . . . . . . . . . . . . . 521 table 457: mpsc receive timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 table 458: mpsc transmit timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 table 459: mii transmit timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 table 460: mii receive timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 table 461: jtag ac characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 table 462: btyp values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 33. pinout table, 492 pin bga ...................................................................................... 533 table 463: gt?96100a pinout table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 34. 492 bga package mechanical information............................................................ 542 35. gt?96100a part numbering.................................................................................... 543 36. abbreviations ........................................................................................................... 544 37. revision history ....................................................................................................... 545 table 464: document history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 GT-96100A advanced communication controller revision 1.0 15 list of figures figure 1: pin list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 5 figure 2: two stage address decoding- conceptual view . . . . . . . . . . . . . . . . . . . . . . 56 figure 3: cpu-side resource group decode function and example . . . . . . . . . . . . . 60 figure 4: device sub-decode function and example . . . . . . . . . . . . . . . . . . . . . . . . . . 61 figure 5: bank size register function example (16meg decode) . . . . . . . . . . . . . . . . 62 figure 6: cpu address remapping to resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 figure 7: double word (8 bytes) read by cpu with parity check bits . . . . . . . . . . . . 77 figure 8: four word (16 bytes) burst read by cpu . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 figure 9: cpu four word burst write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 figure 10: r5000 l2 read miss example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 figure 11: memory controller default arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 figure 12: memory controller modified arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 figure 13: non-staggered refresh waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 figure 14: staggered refresh waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 figure 15: read modify write transaction by the sdram controller . . . . . . . . . . . . . . 100 figure 16: 512 mbit/64-bit sdram connection to memory bus using x8 devices. . . . 108 figure 17: vuma device and the gt?96100a sharing sdram . . . . . . . . . . . . . . . . . 114 figure 18: handing the bus over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 figure 19: mreq* requests from the vuma device . . . . . . . . . . . . . . . . . . . . . . . . . . 116 figure 20: waveform showing device read parameters . . . . . . . . . . . . . . . . . . . . . . . 120 figure 21: waveform showing device write parameters . . . . . . . . . . . . . . . . . . . . . . . 121 figure 22: ready* extending acctofirst on read cycle . . . . . . . . . . . . . . . . . . . . . . . 122 figure 23: ready* extending acctonext on read cycle . . . . . . . . . . . . . . . . . . . . . . . 123 figure 24: extending wractive parameter on write cycle . . . . . . . . . . . . . . . . . . . . . . 124 figure 25: pci master fifos in single 64-bit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 figure 26: pci master fifos in dual 32-bit mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 figure 27: pci target interface ?ping-pong? fifos . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 figure 28: pci target interface fifos operational example . . . . . . . . . . . . . . . . . . . . 159 figure 29: pci configuration header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 figure 30: power management registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 figure 31: i2o circular queue operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 figure 32: chained mode dma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 figure 33: pci arbiter?s interface diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 figure 34: pci arbitration flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 figure 35: ciu connection diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 figure 36: arbiter connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 figure 37: master arbitration flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 GT-96100A advanced communication controller 16 revision 1.0 figure 38: ethernet descriptors and buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 figure 39: ethernet packet transmission example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 figure 40: ethernet tx descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 figure 41: ethernet tx buffer alignment restrictions (5 byte payload) . . . . . . . . . . . . . 259 figure 42: ethernet rx dma descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 figure 43: type of service queueing algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 figure 44: ethernet hash table entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 figure 45: address chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 figure 46: address filtering process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 figure 47: rmii di-bit stream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 figure 48: mii transmit signal timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 figure 49: mii receive signal timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 figure 50: mdio output delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 figure 51: mdio setup and hold time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 figure 52: sdma descriptor format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 figure 53: sdmax configuration register (sdcx). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 figure 54: sdma command register (sdcmx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 figure 55: sdma descriptor pointer registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 figure 56: using auto mode to create idle loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 figure 57: mpsc dpll encoding/decoding schemes . . . . . . . . . . . . . . . . . . . . . . . . . 327 figure 58: mpsc main configuration register (mmcrx) . . . . . . . . . . . . . . . . . . . . . . . 328 figure 59: typical hdlc frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 figure 60: typical localtalk frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 figure 61: mpscx protocol configuration register (mpcrx) for hdlc . . . . . . . . . . . . 339 figure 62: channel registers (chxrx) for hdlc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 figure 63: typical bisync/monosync frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 figure 64: mpscx protocol configuration register (mpcrx) for bisync . . . . . . . . . . 351 figure 65: channel registers (chxrx) for bisync. . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 figure 66: bisync control character register format . . . . . . . . . . . . . . . . . . . . . . . . . 357 figure 67: typical uart frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 figure 68: mpscx protocol configuration register (mpcrx) for uart mode . . . . . . . 363 figure 69: channel registers (chxrx) for uart mode . . . . . . . . . . . . . . . . . . . . . . . . 367 figure 70: uart control character register format. . . . . . . . . . . . . . . . . . . . . . . . . . . 370 figure 71: channel registers (chxrx) for transparent mode. . . . . . . . . . . . . . . . . . . . 375 figure 72: flextdm architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 figure 73: typical iom structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 figure 74: auxiliary channel a control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 figure 75: channel b control register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 figure 76: baud rate generator block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 GT-96100A advanced communication controller revision 1.0 17 figure 77: watchdog register map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 figure 78: filtering circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 figure 79: resistor and capacitor values for vccpll and vsspll . . . . . . . . . . . . . . . 473 figure 80: minimal system configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 figure 81: typical system configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 figure 82: high performance system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 figure 83: power vs. operating frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511 figure 84: tclk = pclk, in sync mode = 1, skew requirement . . . . . . . . . . . . . . . . . . 517 figure 85: flex-tdm receive timing - normal clock waveform . . . . . . . . . . . . . . . . . 518 figure 86: flex-tdm transmit timing - normal speed clock waveform . . . . . . . . . . . 519 figure 87: flex-tdm receive timing - double speed clock waveform. . . . . . . . . . . . 520 figure 88: flex-tdm receive timing - double speed clock waveform. . . . . . . . . . . . 521 figure 89: flex-tdm transmit timing - double speed clock waveform . . . . . . . . . . . 522 figure 90: flex-tdm transmit timing - double speed clock waveform . . . . . . . . . . . 522 figure 91: mpsc receive timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 figure 92: mpsc transmit timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 figure 93: output delay from rts*, asynchronous cts* (ctss=0 in mmcrlx) waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 figure 94: output delay from rts*, synchronous cts* (ctss=1 in mmcrlx) waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 figure 95: output delay from cts*, asynchronous cts* (ctss=0 in mmcrlx) waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 figure 96: output delay from cts*, synchronous cts* (ctss=1 in mmcrlx) waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 figure 97: cts* loss in synchronous protocol: start of frame waveform with cts lost . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 figure 98: cts* loss in synchronous protocol: start of frame waveform without cts lost . . . . . . . . . . . . . . . . . . . . . . . . 527 figure 99: cts* loss in synchronous protocol, synchronous cts* (ctss=1 in mmcrlx) waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 figure 100:cts* loss in synchronous protocol, asynchronous cts* (ctss=0 in mmcrlx) waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 figure 101:reception control using cd* waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 figure 102:external sync (rsyl=0 in mmcrhx), cd* pulse mode (cdm=0 in mmcrlx) waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 figure 103:transmit synchronize to receive (tsyn=1 in mmcrlx), external sync (rsyl=0 in mmcrhx) waveform . . . . . . . . . . . . . . . . . . . . . 528 figure 104:transmit synchronize to receive (tsyn=1 in mmcrlx), external sync (rsyl=0 in mmcrhx), cd* and cts* pulse mode (ctsm=1 and cdm=1 in mmcrlx), synchronous cts* (ctss=1 in mmcrlx) waveform . . . . . . . . . . . . . . . . . 528 figure 105:mii port transmit signals timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 GT-96100A advanced communication controller 18 revision 1.0 figure 106:mii port receive signals timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 figure 107:jtag ac timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 figure 108:gt?96100a pinout map (top view, left side) . . . . . . . . . . . . . . . . . . . . . . . . . 540 figure 109:gt?96100a pinout map (top view, right side). . . . . . . . . . . . . . . . . . . . . . . . 541 figure 110:492 bga package mechanical information. . . . . . . . . . . . . . . . . . . . . . . . . . 542 figure 111:sample part number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 GT-96100A advanced communication controller revision 1.0 19 1. o verview the GT-96100A offers a single-chip solution for designers building communication systems using any high per- formance 64-bit mips cpus. cpus compatible with the GT-96100A include: ? the rm5260, rm5270/1 and rm7000 from qed. ? the rv4600 through rv5000 from idt. ? other r5000 compatibles from various vendors. the GT-96100A integrates a system controller with a communication unit that handles a wide range of serial communication protocols, such as ethernet, fast ethernet, and hdlc. its architecture supports several system implementations for different applications and cost/performance points. also, it is possible to design a powerful system with minimal glue logic, or add commodity logic (controlled by the GT-96100A) for differentiated sys- tem architectures that attain higher performance. the GT-96100A has a three or four bus architecture: ? a 64-bit interface to the cpu bus (sysad bus) ? a 64-bit interface to the memory and device subsystem ? two independent 32-bit pci interfaces or one 64-bit pci interface the three/four buses are de-coupled from each other in most accesses, enabling concurrent operation of the cpu bus, pci devices, and accesses to memory. for example, the GT-96100A can simultaneously support a cpu bus writing to the on-chip write buffer, an idma agent moving data from sdram to its own buffers, and a pci device writing into an on-chip fifo. 1.1 communication unit description the heart of the GT-96100A device is a high-performance wan communications unit. this unit includes: ? eight multi-protocol serial controllers. ? four flextdm time slot assigners. ? two perfect filtering 10/100 ethernet controllers. ? twenty sdma channels. the GT-96100A can directly support several wan interfaces including basic rate isdn (two channels), frame relay, non channelized t1/e1/t3, xdsl (hdsl, vdsl etc.), hssi, and others. 1.1.1 multi-protocol serial controllers the eight multi-protocol serial controllers (mpscs) integrated onto the GT-96100A support uart, hdlc, bisync, and transparent protocols. the mpscs are implemented in the hardware. hardware implementation allows for superior performance when compared to microcoded implementations. GT-96100A advanced communication controller 20 revision 1.0 in hdlc mode, the mpscs perform all framing operations such as bit stuffing/stripping and flag generation, and part of the data link operations (e.g. address recognition functions). the mpscs directly support common hdlc protocols including those used by isdn and frame relay. each mpsc can communicate over dedicated package pins or through one of four flextdm time slot assigners. 1.1.2 flextdm time slot assigners there are four flextdm (time slot assigners) in the GT-96100A. the flextdms support pcm highway, iom1, and iom2 (gci) formats to allow connections to most wan framer and phy devices. the flextdms are fully programmable and can be configured to support almost any proprietary tdm bus. they can also be programed to interface voice codecs and mvip bus peripherals. the flextdm unit includes two auxiliary channels that can be multiplexed onto the tdm highway with data from the eight mpscs. they are optimized for supporting gci bus monitor and c/i channels. 1.1.3 10/100 ethernet controllers there are two 10/100-mbps full duplex ethernet ports in GT-96100A. each port is fully compliant with the ieee 802.3 and 802.3u standards and integrates mac function and a dual speed mii interface. the ports? speed (10 or 100mb/s) and duplex mode (half or full duplex) is auto-negotiated through the phy and does not require user intervention. the ports? logic also supports 802.3x flow-control mode for full-duplex and back-pressure mode for half-duplex. the GT-96100A?s ethernet ports includes galileo?s advanced address filtering capability and can be programmed to accept or reject packets based on mac addresses, thus providing hardware acceleration to complicated tasks such as bridging, routing, and firewall. the ports? can also filter up to 8,000 individual mac addresses. 1.1.4 sdma channels the GT-96100A offers 20 sdma channels to support the eight mpscs and two fast ethernet controllers. the sdma channels are used to transfer data from the various serial ports to the sdram (and vice versa) or over the pci. the sdma channels use linked chain of descriptors and buffers to reduce cpu overhead. table 1 summarizes guaranteed throughput of the mpscs in hdlc mode when the two fast-ethernet ports run at 100mbit/s full wire speed in full duplex mode. table 1: GT-96100A serial performance no. operational mode aggregate bandwidth serial ethernet total 1 4 ports @55 mbps simultaneously 440mbit/s 400mbit/s 840mbit/s 2 6 ports @45 mbps simultaneously 540mbit/s 400mbit/s 940mbit/s 3 all the 8 ports @30 mbps simultaneously 480mbit/s 400mbit/s 880mbit/s GT-96100A advanced communication controller revision 1.0 21 1.2 cpu interface the GT-96100A?s sysad bus allows the cpu and other local bus masters to access the pci and memory/device buses. the sysad bus protocol supports byte, sub-word, 32-bit word, and 64-bit word operations with burst lengths of up to eight words (sub-word, two word, and four word burst length are also supported). with a maximum fre- quency of 100mhz, the cpu can transfer in excess of 800 mbytes/sec. the GT-96100A allows up to four GT-96100A devices, or gt-64120 system controllers, to share the same cpu interface. this significantly increases the address space, number of communication channels, and flexibility of system design. 1 the GT-96100A supports cpu address remapping to resources and can operate in little or big endian mode. 1.3 sdram and device interface the GT-96100A integrates a sdram controller with a 64-bit interface. the sdram controller supports 16, 64, 128, 256 and 512mbit sdrams. it is 3.3v and 5v tolerant, operates at frequencies of up to 100mhz, and can address up to 4gbytes. up to four sdram banks can be connected to the controller and it supports 2 bank interleaving for 16 mbit sdrams and 2 or 4 bank interleaving for 64/128/256/ 512 mbit sdrams. the sdram controller also supports a uma feature that enables external masters to arbitrate for direct access to sdram. this feature enhances system performance and gives flexibility when designing shared memory sys- tems. the GT-96100A device controller supports different types of memory and i/o devices. it has the control signals and timing programmability to support devices such as flash, eproms, fifos, and i/o controllers. device widths from 8-bits to 64-bits are also supported. ecc generation and checking is supported both internally and externally and is optional for each bank of sdram. 1.4 pci interface the GT-96100A interfaces directly to the pci bus. the pci interface can be configured to function as either: ? two 32-bit pci devices (pci_0 and pci_1) ? a single 64-bit pci device (pci_0) operating at a maximum frequency of 66mhz. each of the GT-96100A?s pci interface can either be a master initiating pci bus transaction or a target respond- ing to a pci bus operation. the GT-96100A incorporates 192-bytes of posted write and read prefetch buffers per pci device for efficient data transfer between the cpu bus/dma to pci and pci to main memory. 1. the increased loading will only have a small effect on the system?s maximum operating frequency. GT-96100A advanced communication controller 22 revision 1.0 the GT-96100A becomes a pci bus master when the cpu interface unit or the internal dma engine initiates a bus cycle to a pci device. the following pci bus cycles are supported: ? memory read/write ? interrupt acknowledge ? special ? i/o read/write ? configuration read/write ? locked reads/writes (only for pci_0 slave). the GT-96100A acts as a target when a pci device initiates a memory access (or an i/o access in the case of internal registers). it responds to all memory read/write accesses, as well as to all configuration and i/o cycles in the case of internal registers. it is possible to program the pci slave function to retry all pci transactions targeted to the GT-96100A. the pci slave performs pci address remapping to resources. the GT-96100A includes all required pci configuration registers. all internal registers, including pci configura- tion registers, are accessible from both the cpu bus and the pci bus. GT-96100A configuration register set is pc plug-and-play compatible, with industry standard i 2 o support. the GT-96100A supports pci hot-plug and compactpci hot swap capable requirements. the GT-96100A can also act as a pci to memory bridge and pci communication peripheral, even without the presence of a cpu. 1.5 independent dma (idma) engines the GT-96100A incorporates four high performance idma engines. each idma engine has the capability to transfer data between pci devices, between pci devices and main mem- ory, or between devices residing on the 64-bit device/memory bus. the idma uses two internal 64-byte fifos for temporary storage of idma data. these pair of fifos allows two idma channels to be working concur- rently with each channel utilizing one fifo. for example, while channel 0 is reading data from sdram into one fifo, channel 2 can write data from the other fifo to the pci bus. source and destination addresses can be nonaligned on any byte address boundary. the idma channels can be controlled from the cpu or pci interfaces or via a linked list of records without cpu bus intervention. this linked list is loaded by the idma controller into the channel?s working set when a idma transaction ends. the idma supports increment/decrement/hold on source and destination addresses independently and alignment of addresses towards source and destination. in addition, the GT-96100A provides an override capability of source/ destination/record address mapping to force access to pci_0 or pci_1. idma can be initiated by the cpu writing to a register, an external request via idmareq* pin, or an internal timer/counter. four end-of-transfer pins, which act as inputs to the GT-96100A, allow ending a idma transfer on a certain channel. in case of chained mode, it is possible to transfer the descriptor to cpu ownership after the transfer has ended. the cpu then calculates the number of remaining bytes in the buffer associated with the closed descriptor. fly-by is also supported. this mode allows data to be transferred directly between two residents on the device/ memory bus without having to go into an idma fifo. GT-96100A advanced communication controller revision 1.0 23 1.6 peripheral configurations the GT-96100A provides 88 pins to configure either as peripheral function pins or as general purpose i/os. these pins consist of the following ports: ? six wan ports (a, b, c, d, e, f) with seven pins allocated per port (total of 42 pins). ? two lan port (mii0 and mii1) with 15 pins allocated per port (total of 30 pins). ? one gpp port with 16 pins allocated to it. each of the ports listed above supports multiple internal functions. table 2 shows the configuration options sup- ported for each port. table 2: GT-96100A port configurations port port configuration options a 1. physical interface for mpsc0 2. pci_0 arbiter signals 3. general purpose port b 1. physical interface for mpsc1 2. pci_1 arbiter signals 3. general purpose port c 1. physical interface for mpsc2 2. physical interface for flextdm0 3. general purpose port d 1. physical interface for mpsc3 2. physical interface for flextdm1 3. general purpose port e 1. physical interface for mpsc4 2. physical interface for flextdm2 3. general purpose port f 1. physical interface for mpsc5 2. physical interface for flextdm3 3. general purpose port mii0 1. mii interface for ethernet0 2. physical interface for mpsc6, mpsc7 3. general purpose port mii1 1. mii interface for ethernet1 2. rmii interface for both ethernet0 and ethernet1 3. general purpose port GT-96100A advanced communication controller 24 revision 1.0 table 3 shows typical peripheral configurations supported by the GT-96100A. table 3: GT-96100A peripheral configurations peripheral configuration option port a port b port c port d port e port f port mii0 port mii1 ? two serial ports ? two tdm ports ? one ethernet port mpsc0 mpsc1 tdm0 tdm1 gpp gpp ether0 gpp ? six serial ports ? two ethernet ports mpsc0 mpsc1 mpsc2 mpsc3 mpsc4 mpsc5 ether0 ether1 ? two pci arbiters ? two serial port ? two tdm ports ? two ethernet ports pci_0 arbiter pci_1 arbiter mpsc2 mpsc3 tdm2 tdm3 ether0 ether1 ? one pci arbiter ? three serial ports ? four tdm ports ? one ethernet port pci_0 arbiter mpsc1 tdm0 tdm1 tdm2 tdm3 mpsc6 and mpsc7 ether1 ? eight serial ports ? two ethernet ports mpsc0 mpsc1 mpsc2 mpsc3 mpsc4 mpsc5 mpsc6 and mpsc7 ether0 and ether1 GT-96100A advanced communication controller revision 1.0 25 2. p in i nformation figure 1: pin list pci bus 0 secondary cache interface sdram and devices local address and data bus dma interface test wan gpp cpu interface lan gpp[15:0] pci bus 1 dmareq[3]* / dadr[12] / scas* / eot[0]* / treq* dmareq[2]* / dadr[11] dmareq[1]* / banksel[1] dmareq[0]* / mreq* / sras* ad[41] / devrw* ad[40] / bootcs* ad[39:36] / cs[3:0]* ad[63:42] adp[7:6] / sras*, scas* cstiming* ale ready* / eot[1]* bypsoe* / mgnt* / dwr* ad[35:32] / dmaack[3:0]* ad[31:0] adp[5] / dadr[11] adp[4] / banksel[1] adp[3:1] / eot[3:1]* / dwr* mii0[14:0] mii1[14:0] mdc mdio porta[6:0] portb[6:0] portc[6:0] portd[6:0] portf[6:0] porte[6:0] vref1 pclk1 pad1[31:0] / pad0[63:32] cbe1[3:0]* / cbe0[7:4]* frame1* / req64* irdy1* trdy1* stop1* par1 / par64 vref0 pclk0 pad0[31:0] cbe0[3:0]* frame0* irdy0* trdy0* stop0* lock0* par0 devsel0* req0*/parb0_gnt0 gnt0*/parb0_req0 perr0* serr0* idsel0 validout* validin* wrrdy* release* sysad[63:0] sysadc[7:0] syscmd[8:0] clock/control interface tclk vccpll vsspll scdoe* scmatch sctce* scword[1:0] dwr* dadr[2:0] / badr[2:0] dadr[10:3] / wr[7:0]* banksel[0] sras* scas* scs[3:0]* sdqm[7:0]* jtag[4:0] reset* adp[0] / eot[0]* / dadr[12] interrupt interface interrupt0* interrupt1* serint0* serint1* watchdog interface wde* nmi* bypasspll outmodepll clkoutpll devsel1* / ack64* req1*/parb1_gnt0 gnt1*/parb1_req0 perr1* serr1* idsel1 GT-96100A advanced communication controller 26 revision 1.0 table 4: cpu interface pin assignments pin name type full name description validout* i valid output driven by the cpu to signal a valid address or data on the sysad bus and a valid command or data identifier on the syscmd bus. validin* o valid input driven by the GT-96100A to signal that it is driving valid data on the sysad bus and a valid data identifier on the syscmd bus. wrrdy* o write ready driven by the GT-96100A to signal that it can accept a cpu write request from the cpu (i.e. there is room in the write post- ing fifo). release* i release driven by the cpu to signal that it has released the sysad and syscmd buses for completion of a read request. syscmd[8:0] i/o system com- mand/data identifier bus 9-bit bus used for command and data identifier transmission between the cpu and GT-96100A. sysad[63:0] i/o system address/data bus 64-bit bus used as multiplexed address and data bus for com- munication between the cpu, the GT-96100A, and the l2 cache. sysadc[7:0] i/o system address/data check 8-bit bus used as parity for the sysad bus. sysadc is valid on data cycles only. cpu interface total: 85 table 5: secondary cache interface pin assignments pin name type full name description scdoe* o secondary cache data ram output enable asserted by the GT-96100A to cause the data ram to drive data onto their i/o pins. this signal is monitored by the proces- sor to determine when to drive the data ram write enable in a secondary cache miss refill sequence. this pin must be left unconnected if secondary cache is not used. scmatch i secondary cache tag match asserted by the cache tag ram when a match occurs between the value on its data inputs and the contents of its ram at the value of its address inputs. this pin must be pulled low through a 4.7kohm resistor if secondary cache is not used. GT-96100A advanced communication controller revision 1.0 27 sctce* i secondary cache tag ram chip enable indicates that a secondary cache access is occurring. this pin must be pulled high through a 4.7kohm resistor if secondary cache is not used. scword[1:0] o secondary cache double word index driven by the GT-96100A on cache miss refills. these pins must be left unconnected if secondary cache is not used. secondary cache total: 5 table 6: pci bus 0 pin assignments pin name type full name description vref0 i pci_0 voltage reference must be connected directly to the 3.3v or the 5v power plane, depending on which voltage level pci_0 supports. note: vref0 and vref1 can be completely independent voltage levels. pclk0 i pci_0 clock provides the timing for the pci_0 transactions. the pci_0 clock range is between 0 and 66mhz. note: the pclk0 cycle must be higher than the tclk cycle by at least 1ns. see section 32.1 ?tclk/pclk restric- tions? on page 516 . pad0[31:0] i/o pci_0 address/data 32-bit multiplexed pci_0 address and data lines. during the first clock of the transaction, pad0[31:0] contains a physical byte address (32 bits). during subsequent clock cycles, this contains data. cbe0[3:0]* i/o pci_0 com- mand/byte enable during the address phase of the transaction, cbe0[3:0]* pro- vides the pci_0 bus command. during the data phase, these lines provide the byte enables. par0 i/o pci_0 parity calculated by the GT-96100A as an even parity bit for the pad0[31:0] and cbe0[3:0]* lines. frame0* i/o pci_0 frame asserted by the GT-96100A to indicate the beginning and dura- tion of a master transaction. frame0* asserts to indicate the beginning of the cycle. while asserted, data transfer continues. frame0* deasserts to indicate that the next data phase is the final data phase transaction. frame0* is monitored by the GT-96100A when it acts as a pci target. irdy0* i/o pci_0 initiator ready asserted to indicate the bus master?s ability to complete the current data phase of the transaction. a data phase is com- pleted on any clock when both irdy0* and trdy0* are asserted. wait cycles are inserted until trdy0* and irdy0* are asserted together. table 5: secondary cache interface pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 28 revision 1.0 trdy0* i/o pci_0 target ready asserted to indicate the target agent?s ability to complete the current data phase of the transaction. a data phase is com- pleted on any clock when both trdy0* and irdy0* are asserted. wait cycles are inserted until trdy0* and irdy0* are asserted together. stop0* i/o pci_0 stop asserted to indicate that current target is requesting the bus master to stop the current transaction. as a master, the GT-96100A responds to the assertion of stop0* by disconnecting, retrying, or aborting. as a target, the GT-96100A asserts stop0* to retry or discon- nect. lock0* i pci_0 lock asserted to indicate an automatic operation that may require multiple transactions to complete. when the GT-96100A is a pci_0 target, lock0* is sampled on the rising edge of pclk0 when frame0* is asserted. if lock0* is sampled asserted, the GT-96100A enters a locked state and remains in this state until lock0* is sampled deasserted on the following rising edge of pclk0, when frame0* is sampled asserted. idsel0 i pci_0 initial- ization device select asserted to indicate a chip select during pci_0 configuration read and write transactions. devsel0* i/o pci_0 device select asserted by the target of the current access. when the GT-96100A is bus master, it expects the target to assert devsel0* within five bus cycles, confirming the access. if the target does not assert devsel0* within this time window, the GT-96100A aborts the cycle. as a target, when the GT-96100A recognizes that it is the target of a transaction, it asserts devsel0* at medium speed (two cycles after assertion of frame0*). req0*/ parb0_gnt1 opci_0 bus request if the internal arbiter for pci_0 is disabled, this signal is asserted by the GT-96100A to indicate to the pci_0 bus arbiter that it requires use of the pci_0 bus. pci_0 arbiter output grant 1 if the internal arbiter for pci_0 is enabled, this pin functions as the arbiter?s grant 1 output signal. gnt0*/ parb0_req1 ipci_0 bus grant if the internal arbiter for pci_0 is disabled, this signal is asserted by the external pci_0 bus arbiter to indicate that access to the pci_0 bus is granted to the GT-96100A. pci_0 arbiter input request 1 if the internal arbiter for pci_0 is enabled, this pin functions as the arbiter?s request 1 input signal. table 6: pci bus 0 pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 29 perr0* i/o sts pci_0 parity error asserted when a data parity error is detected. this pin features a sustained tristate output. serr0* od pci_0 system error asserted when a serious system error (not necessarily a pci_0 error) is detected. serr0* behavior in the GT-96100A is pro- grammable (refer to pci section for details). this pin features an open-drain output. pci bus 0 total: 50 table 7: pci bus 1 pin assignments pin name type full name description vref1 i pci_1 voltage reference must be connected directly to the 3.3v or the 5v power plane depending on which voltage level pci_1 supports. note: vref0 and vref1 can be completely independent voltage levels. pclk1 i pci_1 clock provides the timing for pci_1 transactions. the pci_1 clock range is between 0 and 66mhz. runs independently of pclk0. active only when pci _1 is enabled. note: the pclk0 cycle must be higher than the tclk cycle by at least 1ns. this clock frequency can be indepen- dent of both tclk and pclk0. see section 32.1 ?tclk/ pclk restrictions? on page 516 . pad1[31:0]/ pad0[63:32] i/o pci_1 address/data during the first clock of the transaction, pad1[31:0] contains a physical byte address (32 bits). during subsequent clock cycles, pad1[31:0] contains data. pci_0 (64 bit) address/data if pci_0 is configured for 64 bit, these pins function as pad0[63:32] and carry the most significant 32 bits of data for pci_0 transactions. cbe1[3:0]*/ cbe0[7:4]* i/o pci_1 com- mand/byte enable during the address phase of the transaction, cbe1[3:0]* pro- vide the pci_1 bus command. during the data phase, these lines provide the byte enables. pci_0 (64 bit) byte enable if pci_0 is configured for 64 bit, these pins function as cbe0[7:4]* and carry byte enables for the most significant 32 bits of pci_0 data. par1/par64 i/o pci_1 parity calculated by the GT-96100A as an even parity bit for pad1[31:0] and cbe1[3:0]* lines. pci_0 (64 bit) parity if pci_0 is configured for 64 bit, this pin functions as par64 and carries even parity bit for pad0[63:32] and cbe0[7:4]*. table 6: pci bus 0 pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 30 revision 1.0 frame1*/ req64* i/o pci_1 frame asserted by the GT-96100A to indicate the beginning and dura- tion of a master transaction. frame1* asserts to indicate the beginning of the cycle. while asserted, data transfer continues. deasserts to indicate that the next data phase is the final data phase transaction. frame1* is monitored by the GT-96100A when it acts as a target. pci_0 (64 bit) request 64 if pci_0 is configured for 64 bit, this pin functions as req64* and functions as a request for a 64-bit transaction. req64* has the same timing as frame0*. sor sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. irdy1* i/o pci_1 initiator ready asserted to indicate the bus master?s ability to complete the current data phase of the transaction. a data phase is com- pleted on any clock when both irdy1* and trdy1* are asserted. wait cycles are inserted until trdy1* and irdy1* are asserted together. trdy1* i/o pci_1 target ready asserted to indicate the target agent?s ability to complete the current data phase of the transaction. a data phase is com- pleted on any clock when both trdy1* and irdy1* are asserted. wait cycles are inserted until trdy1* and irdy1* are asserted together. stop1* i/o pci_1 stop asserted to indicate the current target is requesting the bus master to stop the current transaction. as a master, the gt- 96100a responds to the assertion of stop1* by disconnecting, retrying or aborting. as a target, the GT-96100A asserts stop1* to retry or disconnect. idsel1 i pci_1 initial- ization device select asserted to indicate a chip select during pci_1 configuration read and write transactions. devsel1*/ ack64* i/o pci_1 device select asserted by the target of the current access. when the gt- 96100a is bus master, it expects the target to assert devsel1* within 5 bus cycles, confirming the access. if the target does not assert devsel1* within this time window, the GT-96100A aborts the cycle. as a target, when the GT-96100A recognizes that it is the target of a transaction, it asserts devsel1* at medium speed (two cycles after assertion of frame1*). pci_1 (64 bit) acknowledge 64 if pci_0 is configured for 64 bit, this signal functions as ack64*. when actively driven by the pci target, it indicates that the tar- get is willing to accept 64 bit data. ack64* has the same timing as devsel0*. table 7: pci bus 1 pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 31 req1*/ parb1_gnt1 o pci_1 bus request if the internal arbiter for pci_1 is disabled, this signal is asserted by the GT-96100A to indicate to the pci_1 bus arbiter that it requires use of the pci_1 bus. pci_1 arbiter output grant 1 if the internal arbiter for pci_1 is enabled, this pin functions as the pci_1 arbiter?s grant 1 output signal. gnt1*/ parb1_req1 i pci_1 bus grant if the internal arbiter for pci_1 is disabled, this signal is asserted by the external pci_1 bus arbiter to indicate that access to the pci_1 bus is granted to the GT-96100A. pci_1 arbiter input request 1 if the internal arbiter for pci_1 is enabled, this pin functions as the pci_1 arbiter?s request 1 input signal. perr1* i/o sts pci_1 parity error asserted when a data parity error is detected. this pin features a sustained tristate output. serr1* od pci_1 system error asserted when a serious system error (not necessarily a pci_1 error) is detected. serr1* behavior in the GT-96100A is pro- grammable (refer to pci section for details). this pin features an open-drain output. pci bus 1 total: 49 table 8: sdram and devices pin assignments pin name type full name description dwr* o sdram write asserted low when the GT-96100A performs a write transaction to the sdram. dadr[2:0]/ badr[2:0] osdram address [2:0] when accessing a sdram bank, these pins function as sdram address bits [2:0]. in write and read accesses from devices these pins function as burst address bits [2:0]. see section 23.2 ?devices? on page 456 for more information on how to connect these address bits to various devices. burst address [2:0] sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. dadr[10:3]/ wr[7:0]* osdram address [10:3] when accessing a sdram bank, these pins function as sdram address bits. in write and accesses to devices these pins function as byte write enable indications for bytes [7:0]. see section 23.2 ?devices? on page 456 for more information on how to connect these address bits to various devices. byte write [7:0] sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. table 7: pci bus 1 pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 32 revision 1.0 banksel[0] o sdram bank select [0] in sdram accesses, this pin functions as bank select bit [0]. sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. sras* o sdram row address strobe asserted to indicate that an active row address is driven on dadr lines. scas* o sdram col- umn address strobe asserted to indicate that an active column address is driven on dadr lines. scs[3:0]* o sdram chip selects sdram chip selects for up to 4 banks. sdqm[7:0]* o sdram byte enables in sdram write transaction these pins function as byte enable signals. sor note: sdqm[3:0] are sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. sdram/devices total: 27 table 9: local address and data bus pin assignments pin name type full name description ad[63:42] i/o address/data [63:42] in sdram accesses, these pins function as part of the data to be read/written from/to the sdrams. in device accesses, these pins function as data during the data phase. ad[41]/ devrw* i/o address/data [41] in sdram/device data phase, this pin functions as data bit [41]. device read- write in device address phase, this pin indicates if an access to a device is read (?1?) or write (?0?). latching is done via ale. ad[40]/ bootcs* i/o address/data [40] in sdram/device data phase, this pin functions as data bit [40]. boot chip select in device address phase, this pin functions as the boot device chip select. latching is done via ale. ad[39:36]/ cs[3:0]* i/o address/data [39:36] in sdram/device data phase, these pins function as data bits [39:36]. chip select [3:0] in device address phase, these pins function as device chip selects and are valid (and should be latched). the chip selects need to be qualified with the cstiming* signal. latching is done via ale. table 8: sdram and devices pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 33 ad[35:32]/ dmaack [3:0]* i/o address/data [35:32] in sdram/device data phase, these pins function as data bits [35:32]. dma acknowl- edge[3:0] in device address phase, these pins function as dma acknowl- edges and are valid (and should be latched). they need to be qualified with the cstiming* signal. latching is done via ale. ad[31:0] i/o address/ data[31:0] multiplexed address and data bus to the sdram (data only) and devices (address and data). adp[7:6]/ sras*/ scas* i/o sdram data ecc [7:6] if the GT-96100A is configured for ecc mode, then in sdram accesses, these pins serve as bits [7:6] of the ecc for data bits [63:0]. ecc is generated by the GT-96100A for 64-bit sdram writes, and read from sdram ecc bank for 64-bit sdram reads. sdram row address strobe adp[7:6] can be configured to function as sras* on reset. see section 22. ?reset configuration? on page 452 . sdram col- umn address strobe adp[7:6] can be configured to function as scas* on reset. see section 22. ?reset configuration? on page 452 . adp[5]/ dadr[11] i/o sdram data ecc [5] if the GT-96100A is configured for ecc mode, then in sdram accesses this pin serve as bit [5] of the ecc for data bits [63:0]. ecc is generated by the GT-96100A for 64 bit sdram writes, and read from sdram ecc bank for 64 bit sdram reads. sdram address [11] if the GT-96100A is configured to non-ecc mode, then in sdram accesses this pin functions as sdram address bit[11]. adp[4]/bank sel[1] i/o sdram data ecc [4] if the GT-96100A is configured for ecc mode, then in sdram accesses this pin serve as bit [4] of the ecc for data bits [63:0]. ecc is generated by the GT-96100A for 64 bit sdram writes, and read from sdram ecc bank for 64 bit sdram reads. sdram bank select [1] if the GT-96100A is configured to non-ecc mode, then in sdram accesses, this pin functions as bank select bit[1]. adp[3:1]/ eot[3:1]*/ dwr* i/o sdram data ecc [3:1] if the GT-96100A is configured for ecc mode, then in sdram accesses, these pins serve as bits [3:1] of the ecc for data bits [63:0]. ecc is generated by the GT-96100A for 64 bit sdram writes, and read from sdram ecc bank for 64 bit sdram reads. end of dma transfer [3:1] if the GT-96100A is configured to non-ecc mode, then in sdram accesses, these pins serve as end of transfer indica- tions for the dma channels. sdram write adp[3] can be configured to function as dwr* on reset. see section 22. ?reset configuration? on page 452 . table 9: local address and data bus pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 34 revision 1.0 adp[0]/ eot[0]*/ dadr[12] i/o sdram data ecc[0] if the GT-96100A is configured for ecc mode, then in sdram accesses, this pin serves as bit [0] of the ecc for data bits [63:0]. ecc is generated by the GT-96100A for 64 bit sdram writes, and read from sdram ecc bank for 64 bit sdram reads. end of dma transfer [0] if the GT-96100A is configured to non-ecc mode, then in sdram accesses, this pin serves as end of transfer indication for dma channel 0. sdram address [12] adp[0] can be configured to function as sdram address [12] on reset. see section 22. ?reset configuration? on page 452 . cstiming* o chip select timing this signal is active (asserted low) for the number of cycles that the device currently being accessed is programmed to. used to qualify cs[3:0]*, bootcs and dmaack[3:0]* signals. sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. ale o address latch enable this signal is asserted in the device address phase and must be used to latch the address, bootcs*, cs[3:0]*, devrw* and dmaack[3:0]* pins from the ad bus. ready*/ eot[1]* i ready this input signal is used as a cycle extender note: when inactive during device access, the access is extended until ready* is asserted. end of trans- fer [1] ready* can be programmed to function as eot[1]*. see sec- tion 5.1.2.3 ?dma end of transfer pins functionality? on page 101 . sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. bypsoe*/ mgnt*/dwr* obypass out- put enable if bypass mode is enabled, this signal controls the output enable for bypass latches/buffers/switches. the bypass can be used when a 64-bit read transaction is executed from the cpu. read data will be transferred directly to the cpu bus. see table 77 . memory (ad) bus grant if the GT-96100A is configured (at reset) for uma support, this pin functions as memory grant. it is asserted in response to mreq*. sdram write this pin can be programmed to function as dwr*. see section 5.1.2.1 ?duplicating sdram control lines? on page 100 . local address total: 76 table 9: local address and data bus pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 35 table 10: dma pin assignments pin name type full name description dmareq[3]*/ dadr[12]/ eot[0]*/ scas*/treq* i/o dma request[3] dma request by external devices to idma channel 3. sdram address [12] this pin can be configured to function as dadr[12]. see section 5.1.2.4 ?multiplexing dadr[12]? on page 102 . uma internal request for uma operation, dmareq[3]* can be programed to indicate that there is a pending internal request in sdram and device interface that requires the GT-96100A ownership of the ad bus. see section 5.6.6 ?total request? on page 117 . end of dma transfer[0] dmareq[3]* can be programmed to function as eot[0]*. see section section 5.1.2.3 ?dma end of transfer pins functional- ity? on page 101 . sdram col- umn address strobe dmareq[3]* can be programmed to function as scas*. see section 5.1.2.1 ?duplicating sdram control lines? on page 100 . sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. dmareq[2]*/ dadr[11] i/o dma request[2] dma request by external devices to idma channel 2. sdram address [11] this pin can be configured to function as sdram address bit[11]. see section 5.1.2.2 ?duplicating dadr[11] and bank- sel[1] on dmareq[2:1]*? on page 101 . sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. dmareq[1]*/ banksel[1] i/o dma request[1] dma request by external devices to idma channel 1. sdram bank select [1] this pin can be configured to function as banksel[1]. see sec- tion 5.1.2.2 ?duplicating dadr[11] and banksel[1] on dmareq[2:1]*? on page 101 . sor note: sampled on reset to configure the GT-96100A prior to boot-up. see section 22. ?reset configuration? on page 452 for more information. dmareq[0]*/ mreq*/ sras* i/o dma request [0] dma request by external devices to idma channel 0. memory bus request if the GT-96100A is configured (at reset) for uma support, this pin functions as memory request. sdram row address strobe this pin can be programmed to function as sras*. see sec- tion 5.1.2.1 ?duplicating sdram control lines? on page 100 . dma total: 4 GT-96100A advanced communication controller 36 revision 1.0 table 11: wan pin assignments pin name type full name description port a note: port a can be connected to mpsc0. see section 20. ?physical signal routing? on page 414 for more details. when not connected to mpsc0, port a can be connected to the pci arbiter or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. porta[0] i/o rxd0 (input) serial receive data input to mpsc0. parb0_gnt2 (output) pci_0 arbiter output grant 2. gpp16 (i/o) general purpose pin 16. porta[1] i/o parb0_req2 (input) pci_0 arbiter input request 2. txd0 (output) serial transmit data output from the mpsc0. gpp17 (i/o) general purpose pin 17. porta[2] i/o parb0_req3 (input) pci_0 arbiter input request 3. rts0* (output) request to send output from mpsc0. indicates that mpsc0 is ready to transmit data. gpp18 (i/o) general purpose pin 18. porta[3] i/o cts0* (input) clear to send input to mpsc0. indicates to mpsc0 that data transmission may begin. parb0_gnt3 (output) pci_0 arbiter output grant 3. gpp19 (i/o) general purpose pin 19. porta[4] i/o cd0 (input) carrier detect input to mpsc0. indicates to mpsc0 that it can begin reception of data. parb0_gnt4 (output) pci_0 arbiter output grant 4. gpp20 (i/o) general purpose pin 20. porta[5] i/o sclk0 (input) input clock to mpsc0. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. parb0_req4 (input) pci_0 arbiter input request 4. osclk0 (out- put) output clock from mpsc0. can be used when sclk0 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms). gpp21 (i/o) general purpose pin 21. GT-96100A advanced communication controller revision 1.0 37 port a (continued) porta[6] i/o tsclk0 (input) input clock to mpsc0. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. parb0_req5 (input) pci_0 arbiter input request 5. otsclk0 (output) output tx clock from mpsc0. can be used when tsclk0 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). gpp22 (i/o) general purpose pin 22. port b note: port b can be connected to mpsc1. see section 20. ?physical signal routing? on page 414 for more details. when not connected to mpsc1, port b can be connected to the pci arbiter or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. portb[0] i/o rxd1 (input) serial receive data input to mpsc1. parb1_gnt2 (output) pci_1 arbiter output grant 2. gpp24 (i/o) general purpose pin 24. portb[1] i/o parb1_req2 (input) pci_1 arbiter input request 2. txd1 (output) serial transmit data output from the mpsc1. gpp25 (i/o) general purpose pin 25. portb[2] i/o parb1_req3( input) pci_1 arbiter input request 3. rts1* (output) request to send output from mpsc1. indicates that mpsc1 is ready to transmit data. gpp26 (i/o) general purpose pin 26. portb[3] i/o cts1* (input) clear to send input to mpsc1. indicates to mpsc1 that data transmission may begin. parb1_gnt3 (output) pci_1 arbiter output grant 3. pp27 (i/o) general purpose pin 27. table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 38 revision 1.0 port b (continued) portb[4] i/o cd1 (input) carrier detect input to mpsc1. indicates to mpsc1 that it can begin reception of data. parb0_gnt6 (output) pci_0 arbiter output grant 6. parb1_gnt4 (output) pci_1 arbiter output grant 4. gpp28 (i/o) general purpose pin 28. portb[5] i/o sclk1 (input) input clock to mpsc1. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. parb0_req6 (input) pci_0 arbiter input request6. parb1_req4 (input) pci_1 arbiter input request 4. osclk1 (out- put) output clock from mpsc1. can be used when sclk1 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms). gpp29 (i/o) general purpose pin 29. portb[6] i/o tsclk1 (input) input clock to mpsc1. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. otsclk1 (output) output tx clock from mpsc1. can be used when tsclk1 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). parb0_gnt5 (output) pci_0 arbiter output grant 5. gpp30 (i/o) general purpose pin 30. table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 39 port c note: port c can be connected to mpsc2. see section 20. ?physical signal routing? on page 414 for more details. when not connected to mpsc2, port c can be connected to tdm0 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. portc[0] i/o rxd2 (input) serial receive data input to mpsc2. trxd0 (input) serial receive data input to tdm channel0. ttxd0 (out- put) serial transmit data from tdm channel0. gpp32 (i/o) general purpose pin 32. portc[1] i/o txd2 (output) serial transmit data output from the mpsc2. ttxd0 (out- put) serial transmit data from tdm channel0. trxd0 (input) serial receive data input to tdm channel0. gpp33 (i/o) general purpose pin 33. portc[2] i/o rts2* (output) request to send output from mpsc2. indicates that mpsc2 is ready to transmit data. tdstrb0 (output) tdm channel0 strobe output signal, which can be used to gate clocks to external devices that do not have a built in tdm. gpp34 (i/o) general purpose pin 34. portc[3] i/o cts2* (input) clear to send input to mpsc2. indicates to mpsc2 that data transmission may begin. ttsync0 (input) transmit frame sync input to tdm channel0. gpp35 (i/o) general purpose pin 35. portc[4] i/o cd2 (input) carrier detect input to mpsc2. indicates to mpsc2 that it can begin reception of data (input to mpsc2). trsync0 (input) receive frame sync input to tdm channel0. gpp36 (i/o) general purpose pin 36. table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 40 revision 1.0 port c (continued) portc[5] i/o sclk2 (input) input clock to mpsc2. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. osclk2 (out- put) output clock from mpsc2. can be used when sclk2 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms). trclk0 (input) receive input clock to tdm channel0. gpp37 (i/o) general purpose pin 37. portc[6] i/o tsclk2 (input) input clock to mpsc2. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. otsclk2 (output) output tx clock from mpsc2. can be used when tsclk2 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). ttclk0 (input) transmit input clock to tdm channel0. gpp38 (i/o) general purpose pin 38. port d note: port d can be connected to mpsc3. see section 20. ?physical signal routing? on page 414 for more details. when not connected to mpsc3, port d can be connected to tdm1 or used as gpp . see section 19. ?general purpose ports? on page 405 for more details. portd[0] i/o rxd3 (input) serial receive data input to mpsc3. trxd1 (input) serial receive data input to tdm channel1. ttxd1 (out- put) serial transmit data from tdm channel1. gpp40 (i/o) general purpose pin 40. portd[1] i/o txd3 (output) serial transmit data output from the mpsc3. ttxd1 (out- put) serial transmit data from tdm channel1. trxd1 (input) serial receive data input to tdm channel1. gpp41 (i/o) general purpose pin 41. table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 41 port d (continued) portd[2] i/o rts3* (output) request to send output from mpsc3. indicates that mpsc3 is ready to transmit data. tdstrb1 (output) tdm channel1 strobe output signal, which can be used to gate clocks to external devices that do not have a built in tdm. gpp42 (i/o) general purpose pin 42. portd[3] i/o cts3* (input) clear to send input to mpsc3. indicates to mpsc3 that data transmission may begin. ttsync1 (input) transmit frame sync input to tdm channel1. gpp43 (i/o) general purpose pin 43. portd[4] i/o cd3 (input) carrier detect input to mpsc3. indicates to mpsc3 that it can begin reception of data (input to mpsc3). trsync1 (input) receive frame sync input to tdm channel1. gpp44 (i/o) general purpose pin 44. portd[5] i/o sclk3 (input) input clock to mpsc3. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. osclk3 (out- put) output clock from mpsc3. can be used when sclk3 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms). trclk1 (input) receive input clock to tdm channel1. gpp45 (i/o) general purpose pin 45. portd[6] i/o tsclk3 (input) input clock to mpsc3. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. otsclk3 (output) output tx clock from mpsc3. can be used when tsclk3 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). ttclk1 (input) transmit input clock to tdm channel1. gpp46 (i/o) general purpose pin 46. table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 42 revision 1.0 port e note: port e can be connected to mpsc4. see section 20. ?physical signal routing? on page 414 for more details. when not connected to mpsc4, port e can be connected to tdm2 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. porte[0] i/o rxd4 (input) serial receive data input to mpsc4. trxd2 (input) serial receive data input to tdm channel2. ttxd2 (out- put) serial transmit data from tdm channel2. gpp48 (i/o) general purpose pin 48. porte[1] i/o txd4 (output) serial transmit data output from the mpsc4. ttxd2 (out- put) serial transmit data from tdm channel2. trxd2 (input) serial receive data input to tdm channel2. gpp49 (i/o) general purpose pin 49. porte[2] i/o rts4* (output) request to send output from mpsc4. indicates that mpsc4 is ready to transmit data. tdstrb2 (output) tdm channel2 strobe output signal, which can be used to gate clocks to external devices that do not have a built in tdm. gpp50 (i/o) general purpose pin 50. porte[3] i/o cts4* (input) clear to send input to mpsc4. indicates to mpsc4 that data transmission may begin. ttsync2 (input) transmit frame sync input to tdm channel2. gpp51 (i/o) general purpose pin 51. porte[4] i/o cd4 (input) carrier detect input to mpsc4. indicates to mpsc4 that it can begin reception of data (input to mpsc4). trclk2 (input) receive input clock to tdm channel2. gpp52 (i/o) general purpose pin 52. table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 43 port e (continued) porte[5] i/o sclk4 (input) input clock to mpsc4. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. osclk4 (out- put) output clock from mpsc4. can be used when sclk4 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms). trsync2 (input) receive frame sync input to tdm channel2. gpp53 (i/o) general purpose pin 53. porte[6] i/o tsclk4 (input) input clock to mpsc4. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. otsclk4 (output) output tx clock from mpsc4. can be used when tsclk4 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). ttclk2 (input) transmit input clock to tdm channel2. gpp54 (i/o) general purpose pin 54. port f note: port f can be connected to mpsc5. see section 20. ?physical signal routing? on page 414 for more details. when not connected to mpsc5, port f can be connected to tdm3 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. portf[0] i/o rxd5 (input) serial receive data input to mpsc5. trxd3 (input) serial receive data input to tdm channel3. ttxd3 (out- put) serial transmit data from tdm channel3. gpp56 (i/o) general purpose pin 56. portf[1] i/o txd5 (output) serial transmit data output from the mpsc5. ttxd3 (out- put) serial transmit data from tdm channel3. trxd3 (input) serial receive data input to tdm channel3. gpp57 (i/o) general purpose pin 57. table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 44 revision 1.0 port f (continued) portf[2] i/o rts5* (output) request to send output from mpsc5. indicates that mpsc5 is ready to transmit data. tdstrb3 (output) tdm channel3 strobe output signal, which can be used to gate clocks to external devices that do not have a built in tdm. gpp58 (i/o) general purpose pin 58. portf[3] i/o cts5* (input) clear to send input to mpsc5. indicates to mpsc5 that data transmission may begin. ttsync3 (input) transmit frame sync input to tdm channel3. gpp59 (i/o) general purpose pin 59. portf[4] i/o cd5 (input) carrier detect input to mpsc5. indicates to mpsc5 that it can begin reception of data (input to mpsc5). trclk3 (input) receive input clock to tdm channel3. gpp60 (i/o) general purpose pin 60. portf[5] i sclk5 (input) input clock to mpsc5. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. osclk5 (out- put) output clock from mpsc5. can be used when sclk5 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms). trsync3 (input) receive frame sync input to tdm channel3. gpp61 (i/o) general purpose pin 61. portf[6] i/o tsclk5 (input) input clock to mpsc5. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. otsclk5 (output) output tx clock from mpsc5. can be used when tsclk5 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). ttclk3 (input) transmit input clock to tdm channel3. gpp62 (i/o) general purpose pin 62. wan total: 42 table 11: wan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 45 table 12: lan pin assignments pin name type full name description port mii0 note: port mii0 can be connected to mpsc6 and/or mpsc7. see section 20. ?physical signal routing? on page 414 for more details. when not connected to mpsc6 and mpsc7, port mii0 is connected to ethernet 0 or used as gpp. section 19. ?general purpose ports? on page 405 for more details. mii0[0] i/o mtxen0 - mii0 transmit enable (out- put) indicates that a packet is being transmitted to the phy. mtxen0 is synchronous to mtxclk0. gpp64 (i/o) general purpose pin 64. mii0[1] i/o mtxclk0 - mii0 transmit clock (input) provides the timing reference for the transfer of the mtxen0, mtxd0 signals. it operates at either 25 mhz (100mbps) or 2.5 mhz (10mbps). tsclk6 (input) input clock to mpsc6. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. otsclk6 (output) output tx clock from mpsc6. can be used when tsclk6 is not needed (i.e. the mpsc is pro- grammed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). gpp65 (i/o) general purpose pin 65. mii0[2] i/o mtxd0[3] - mii0 transmit data bit [3] (output) data nibble bit [3] output to the external phy device. synchro- nous to mtxclk0. rts6* (out- put) request to send output from mpsc6. indicates that mpsc6 is ready to transmit data. gpp66 (i/o) general purpose pin 66. mii0[3] i/o mtxd0[2] - mii0 transmit data bit [2] (output) data nibble bit [2] output to the external phy device. synchro- nous to mtxclk0. txd6 (output) serial transmit data output from the mpsc6. gpp67 (i/o) general purpose pin 67. GT-96100A advanced communication controller 46 revision 1.0 port mii0 (continued) mii0[4] i/o mtxd0[1] - mii0 transmit data bit [1] (output) data nibble bit [1] output to the external phy device. synchro- nous to mtxclk0. rts7* (out- put) request to send output from mpsc7. indicates that mpsc7 is ready to transmit data. gpp68 (i/o) general purpose pin 68. mii0[5] i/o mtxd0[0] - mii0 transmit data bit [0] (output) data nibble bit [0] output to the external phy device. synchro- nous to mtxclk0. txd7 (output) serial transmit data output from the mpsc7. gpp69 (i/o) general purpose pin 69. mii0[6] i/o mcol0 - mii0 collision detect (input) indicates that a collision has been detected on the wire. note: this input is ignored in half - and full-duplex mode mode when mtxen0 is low. mcol0 is asynchronous. tsclk7 (input) input clock to mpsc7. can be used by the mpsc transmitter when separate receive and transmit clocks are needed. note: this clock also serves as one of the input clocks to the baud rate generators. otsclk7 (output) output tx clock from mpsc7. can be used when tsclk7 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms, or when there is no need for a separate tx clock). gpp70 (i/o) general purpose pin 70. mii0[7] i/o mrxd0[3] - mii0 receive data bit [3] (input) data nibble bit [3] input from external phy. synchronous to mrxclk0. cts6* (input) clear to send input to mpsc6. indicates to mpsc6 that data transmission may begin. gpp71 (i/o) general purpose pin 71. mii0[8] i/o mrxd0[2] - mii0 receive data bit [2] (input) data nibble bit [2] input from external phy. synchronous to mrxclk0. rxd6 (input) serial receive data input to mpsc6. gpp72 (i/o) general purpose pin 72. table 12: lan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 47 port mii0 (continued) mii0[9] i/o mrxd0[1] - mii0 receive data bit [1] (input) data nibble bit [1] input from external phy. synchronous to mrxclk0. cts7* (input) clear to send input to mpsc7. indicates to mpsc7 that data transmission may begin. gpp73 (i/o) general purpose pin 73. mii0[10] i/o2 mrxd0[0] - mii0 receive data bit [0] (input) data nibble bit [0] input from external phy. synchronous to mrxclk0. rxd7 (input) serial receive data input to mpsc7. gpp74 (i/o) general purpose pin 74. mii0[11] i/o mrxer0 - mii0 receive error (input) indicates that an error was detected in the received frame. this input is ignored when mrxdv0 is inactive. cd6 (input) carrier detect input to mpsc6. indicates to mpsc6 that it can begin reception of data. gpp75 (i/o) general purpose pin 75. mii0[12] i/o mrxclko (input) provides the timing reference for the transfer of the mrxdv0, mrxd0 and mrxer0 signals. operates at either 25 mhz (100mbps) or 2.5 mhz (10mbps). note: the nominal frequency of mrxclk0 must match the nominal frequency of mtxclk0. sclk6 (input) input clock to mpsc6. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. osclk6 (out- put) output clock from mpsc6. can be used when sclk6 is not needed (i.e. the mpsc is pro- grammed to use one of the baud rate generators as its clock source or is connected to one of the tdms). gpp76 (i/o) general purpose pin 76. table 12: lan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 48 revision 1.0 port mii0 (continued) mii0[13] i/o mrxdv0 - mii0 receive data valid (input) indicates that valid data is present on rxd0 lines. synchronous to mrxclk0. sclk7 (input) input clock to mpsc7. can be used as both transmit and receive clock. note: this clock also serves as one of the input clocks to the baud rate generators. osclk7 (out- put) output clock from mpsc7. can be used when sclk7 is not needed (i.e. the mpsc is programmed to use one of the baud rate generators as its clock source or is connected to one of the tdms). gpp77 (i/o) general purpose pin 77. mii0[14] i/o mcrs0 - mii0 carrier sense (input) in half duplex mode, indicates that either the transmit or receive medium is non-idle. note: mcrs0 is ignored in full-duplex. cd7 (input) carrier detect input to mpsc7. indicates to mpsc7 that it can begin reception of data. gpp78 (i/o) general purpose pin 78. port mii1 mii1[0] i/o mtxen1 - mii1 transmit enable (out- put) indicates that a packet is being transmitted to the phy. mtxen1 is synchronous to mtxclk1. gpp80 (i/o) general purpose pin 80. rmtxen1 (output) transmit enable for ethernet port 1. mii1[1] i/o mtxclk1 - mii1 transmit clock (input) provides the timing reference for the transfer of the mtxen1, mtxd1 signals. it operates at either 25 mhz (111mbps) or 2.5 mhz (11mbps). note: port mii1 can be connected to ethernet 1. see section 20. ?physical signal routing? on page 414 for more details. when not connected to ethernet 1, port mii1 is con- nected to ethernet 0 and ethernet 1 rmii interfaces or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. gpp81 (i/o) general purpose pin 81. rm50clk (input) rmii clock input (50mhz) table 12: lan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 49 port mii1 (continued) mii1[2] i/o mtxd1[3] - mii1 transmit data bit [3] (output) data nibble bit [3] output to the external phy device. synchro- nous to mtxclk1. gpp82 (i/o) general purpose pin 82. rmtxd0[1] (output) rmii transmit data bit [1] for port 0. mii1[3] i/o mtxd1[2] - mii1 transmit data bit [2] (output) data nibble bit [2] output to the external phy device. synchro- nous to mtxclk1. gpp83 (i/o) general purpose pin 83. rmtxd0[0] (output) rmii transmit data bit [0] for port 0. mii1[4] i/o mtxd1[1] - mii1 transmit data bit [1] (output) data nibble bit [1] output to the external phy device. synchro- nous to mtxclk1. gpp84 (i/o) general purpose pin 84. rmtxd1[1] (output) rmii transmit data bit [1] for port 1. mii1[5] i/o mtxd1[0] - mii1 transmit data bit [0] (output) data nibble bit [0] output to the external phy device. synchro- nous to mtxclk1. rmtxd1[0] (output) rmii transmit data bit [0] for port 1. gpp85 (i/o) general purpose pin 85. mii1[6] i/o mcol1 - mii1 collision detect (input) indicates that a collision has been detected on the wire. note: this input is ignored in half- and full-duplex mode when mtxen1 is low. mcol1 is asynchronous. gpp86 (i/o) general purpose pin 86. rmtxen0 (output) rmii transmit enable for ethernet port 0. table 12: lan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 50 revision 1.0 port mii1 (continued) mii1[7] i/o mrxd1[3] - mii1 receive data bit [3] (input) data nibble bit [3] input from external phy. synchronous to mrxclk1. gpp87 (i/o) general purpose pin 87. rmrxd0[1] (input) rmii receive data bit [1] for port 0. mii1[8] i/o mrxd1[2] - mii1 receive data bit [2] (input) data nibble bit [2] input from external phy. synchronous to mrxclk1. gpp88 (i/o) general purpose pin 88. rmrxd0[0] (input) rmii receive data bit [0] for port 0. mii1[9] i/o mrxd1[1] - mii1 receive data bit [1] (input) data nibble bit [1] input from external phy. synchronous to mrxclk1. gpp89 (i/o) general purpose pin 89. rmrxd1[1] (input) rmii receive data bit [1] for port 1. mii1[10] i/o mrxd1[0] - mii1 receive data bit [0] (input) data nibble bit [0] input from external phy. synchronous to mrxclk1. gpp90 (i/o) general purpose pin 90. rmrxd1[0] (input) rmii receive data bit [0] for port 1. mii1[11] i/o mrxer1 - mii1 receive error (input) indicates that an error was detected in the received frame. note: this input is ignored when mrxdv1 is inactive. gpp91 (i/o) general purpose pin 91. table 12: lan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 51 port mii1 (continued) mii1[12] i/o mrxclk1 - mii1 receive clock (input) provides the timing reference for the transfer of the mrxdv1, mrxd1 and mrxer1 signals. operates at either 25 mhz (111mbps) or 2.5 mhz (11mbps). note: the nominal frequency of mrxclk1 must match the nominal frequency of mtxclk1. gpp92 (i/o) general purpose pin 92. mii1[13] i/o mrxdv1 - mii1 receive data valid (input) indicates that valid data is present on rxd1 lines. synchronous to mrxclk1. gpp93 (i/o) general purpose pin 93. rmcrsdv1 (input) rmii crs_dv for port 1. mii1[14] i/o mcrs1 - mii1 carrier sense (input) in half-duplex mode, indicates that either the transmit or receive medium is non-idle. mcrs1 is ignored in full-duplex. gpp94 (i/o) general purpose pin 94. rmcrsdv0 (input) rmii crs_dv for port 0. port mdc and mdio mdc o mii manage- ment inter- face clock signal mii management serial data transfers are clocked by this clock output. mdio i/o mii manage- ment inter- face data signal mii management serial data to and from the phys is transmitted on this line. lan total: 32 table 13: gpp pin assignments pin name type full name description gpp[0] i/o bclk0 (input) one of the input clocks that can be used for the baud rate generators. gpp0 (i/o) general purpose i/o pin for system use. table 12: lan pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 52 revision 1.0 gpp[1] i/o bclk1 (input) one of the input clocks that can be used for the baud rate generators. gpp1 (i/o) general purpose i/o pin for system use. gpp[2] i/o brgo0 (out- put) baud rate generator?s output (from baud rate generator 0). gpp2 (i/o) general purpose i/o pin for system use. gpp[3] i/o brgo1 (out- put) baud rate generator?s output (from baud rate generator 1). gpp3 (i/o) general purpose i/o pin for system use. gpp[4] i/o trclk0 (input) input receive clock to tdm channel0. gpp4 (i/o) general purpose i/o pin for system use. gpp[5] i/o trclk1 (input) input receive clock to tdm channel1. gpp5 (i/o) general purpose i/o pin for system use. gpp[6] i/o trclk2 (input) input receive clock to tdm channel2. otsclk4 (output) output tx clock from mpsc4. gpp6 (i/o) general purpose i/o pin for system use. gpp[7] i/o trclk3 (input) input receive clock to tdm channel3. otsclk5 (output) output tx clock from mpsc5. gpp7 (i/o) general purpose i/o pin for system use. gpp[8] i/o toclk0 (out- put) output clock from tdm channel0. gpp8 (i/o) general purpose i/o pin for system use. gpp[9] i/o toclk1 (out- put) output clock from tdm channel1. gpp9 (i/o) general purpose i/o pin for system use. gpp[10] i/o toclk2 (out- put) output clock from tdm channel2. otsclk2 (output) output tx clock from mpsc2. gpp10 (i/o) general purpose i/o pin for system use. table 13: gpp pin assignments (continued) pin name type full name description GT-96100A advanced communication controller revision 1.0 53 gpp[11] i/o toclk3 (out- put) output clock from tdm channel3. otsclk3 (output) output tx clock from mpsc3. gpp11 (i/o) general purpose i/o pin for system use. gpp[12] i/o/od a general purpose i/o pin for system use. when configured as functional output, this pin features an open-drain output. note: see section 19. ?general purpose ports? on page 405 for details about gpp configuration options. gpp[13] i/o/od a general purpose i/o pin for system use. when configured as functional output, this pin features an open-drain output. note: see section 19. ?general purpose ports? on page 405 for details about gpp configuration options. gpp[14] i/o a general purpose i/o pin for system use. gpp[15] i/o a general purpose i/o pin for system use. gpp total: 16 table 14: interrupt interface pin assignments pin name type full name description interrupt0* i/o interrupt0 driven by the GT-96100A to signal that one (or more) of the internal (unmasked) interrupt sources within the GT-96100A is set. interrupt1* od interrupt1 driven by the GT-96100A to signal that one (or more) of the internal (unmasked) interrupt sources within the GT-96100A is set. this pin features an open-drain output. serint0* i/o serial interrupt0 driven by the GT-96100A to signal that one (or more) of the internal (unmasked) serial interrupt sources within the gt- 96100a is set. this signal is dedicated only to interrupt events that occur within the communication unit. serint1* i/o serial interrupt1 driven by the GT-96100A to signal that one (or more) of the internal (unmasked) serial interrupt sources within the gt- 96100a is set. this signal is dedicated only to interrupt events that occur within the communication unit. interrupt total: 4 table 13: gpp pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 54 revision 1.0 table 15: watchdog interface pin assignments pin name type full name description wde* i/o watchdog expired (out- put) asserts to indicate that the watchdog timer in the GT-96100A expired. nmi* i/o non maskable interrupt (out- put) asserted by the GT-96100A to indicate that a non maskable interrupt is pending. watchdog total: 2 table 16: test interface pin assignments pin name type full name description jtag[0] i tclk - jtag clock input clock for test logic. tms and tdi are received on the ris- ing edge, tdo is driven from the falling edge. this signal deter- mines the shifting rate. jtag[1] i tms - jtag mode select a broadcast test signal that controls test logic operation. jtag[2] i tdi - jtag data in serial data input. jtag[3] o tdo - jtag data out serial data output. tristate changes on negative change of jtclk. jtag[4] i trst - jtag reset asynchronous reset to the jtag controller. test total: 5 table 17: clock/control interface pin assignments pin name type full name description tclk i clock master clock input to the GT-96100A (up to 100mhz). tclk is used for the sysad interface and the device interface. tclk must be driven for all applications. reset* i reset must be asserted for any reset sequence. vccpll i vcc for pll used for supplying a low-noise power to the internal pll. vsspll i vss for pll used for supplying a low-noise ground to the internal pll. bypasspll i bypass pll this is used for pll bypass mode: 0 - pll is not bypassed (normal mode) 1 - pll is bypassed GT-96100A advanced communication controller revision 1.0 55 outmodepll i output mode pll clock this pin controls the clock output function of the pll: 0 - pll generated clock is driven on clkoutpll pin. 1 - pll generated clock is not driven out (i.e. clkoutpll pin is in hi-z state). clkoutpll o clock output for pll this pin is used for driving the pll generated clock. to enable this pin, the outmodepll pin must be pulled low. clock/control total: 7 table 17: clock/control interface pin assignments (continued) pin name type full name description GT-96100A advanced communication controller 56 revision 1.0 3. a ddress s pace d ecoding the GT-96100A has a fully programmable address map. two address spaces exist: the cpu address space and the pci address space (see figure 2 .) both address maps use a two-stage decoding process where major device regions are decoded first, then the individual devices are subdecoded. figure 2: two stage address decoding- conceptual view to pci_0 bus pci base address registers processor decode registers to pci_1 bus (if configured for pci_0 and pci_1) sdram bank scs0 -or- scs1 sdram bank scs3 -or- scs2 devices (multiple decoders) device decoders scs0 bank scs1 bank scs2 bank scs3 bank bootcs* cs0* cs1* cs2* cs3* device control signals device bus (ad bus) sdram bank scs0 -or- scs1 sdram bank scs3 -or- scs2 pci_0 memory0 window pci_0 i/o window devices (multiple decoders) pci_0 memory1 window pci_1 i/o window pci_1 memory0 window pci_1 memory1 window internal GT-96100A registers GT-96100A internal registers GT-96100A internal registers GT-96100A advanced communication controller revision 1.0 57 3.1 two stage decoding process the system resources are divided into the following groups: ?scs[1:0]* ?scs[3:2]* ?cs[2:0]* ? cs[3] & bootcs* ? internal registers ?pci_0 i/o ? pci_0 memory0/1 ?pci_1 i/o ? pci_1 memory0/1 note: pci_1 i/0 and pci_1 memory0/1 will only exist if the GT-96100A is configured for both pci_0 and pci_1. each group can have a minimum of 2 mbytes and a maximum of 4 gbytes of address space. the individual devices in the device groups are further sub decoded to 1 mbyte resolution. table 18 shows the cpu decode and device sub-decode associations. table 19 shows the same process for pci_0 and table 20 shows the process for pci_1. table 18: cpu and device decoder mappings cpu decoder associated device sub-decoders scs[1:0]* scs[0]* scs[1]* scs[3:2]* scs[2]* scs[3]* cs[2:0]* cs0* cs1* cs2* bootcs*/cs3* bootcs* cs3* pci_0 i/o none. accesses decoded for pci_0 i/o are bridged to pci_0 i/o transfers. pci_0 memory 0/1 none. accesses decoded for pci_0 memory 0/1 are bridged to pci memory transfers. pci_1 i/o none. accesses decoded for pci_1 i/o are bridged to pci_1 i/o transfers. pci_1 memory 0/1 none. accesses decoded for pci_1 memory 0/1 are bridged to pci_1 memory transfers. internal none. decodes to the GT-96100A internal registers. GT-96100A advanced communication controller 58 revision 1.0 table 19: pci_0 base address register and device decoder mappings pci base address register (bar) decoder 1 1. this mapping also applies to the swap bars located in pci function 1, if enabled. associated device sub-decoders scs[1:0] * - bar 0 at 0x10 scs0* scs1* scs[3:2]* - bar 1 at 0x14 scs2* scs3* cs[2:0]* - bar 2 at 0x18 cs0* cs1* cs2* bootcs*/cs3* - bar 3 at 0x1c bootcs* cs3* internal registers (memory) - bar 4 at 0x20 none decodes pci_0 memory accesses to the GT-96100A internal registers. internal registers (i/o) - bar 5 at 0x24 none. decodes pci_0 i/o accesses to the GT-96100A internal registers. expansion rom - bar at 0x30 none. decodes directly to cs3*. table 20: pci_1 base address register and device decoder mappings pci base address register (bar) decoder 1 associated device sub-decoders scs[1:0]* - bar 0 at 0x90 scs0* scs1* scs[3:2]* - bar 1 at 0x94 scs2* scs3* cs[2:0]* - bar 2 at 0x98 cs0* cs1* cs2* bootcs*/cs3* - bar 3 at 0x9c bootcs* cs3* internal registers (memory) - bar 4 at 0xa0 none. decodes pci_1 memory accesses to the GT-96100A internal registers. GT-96100A advanced communication controller revision 1.0 59 3.1.1 cpu side decoding process decoding on the cpu side starts with the sysad address being compared with the values in the various cpu low and high decoder registers. for example, the scs[1:0]* cpu high and low decoder registers set the address range in which the scs0* and scs1* signals are active (i.e. where dram banks 0 and 1 are located.) the comparison works as follows: 1. bits 35:32 of the sysad address are compared against bits 14:11 in the various cpu low decode regis- ters. these values must match exactly. this effectively sets a 4 gbyte ?page? for the resource group. 2. bits 31:21 of the sysad address are compared against bits 10:0 in the various cpu low decode regis- ters. the value of the sysad bits must be greater than or equal to the low decode value. this sets the lower boundary for the region. 3. bits 31:21 of the sysad address are compared against the high decode registers. the value of the sysad bits must be less than or equal to this value. this sets the upper bound for the region. 4. if all of the above are true, then the resource group is selected and a subdecode is performed to deter- mine the specific resource. an example of the cpu resource group decode process is shown in figure 3 . internal registers (i/o) - bar 5 at 0xa4 none. decodes pci_1 i/o accesses to the GT-96100A internal registers. 1. this mapping also applies to the swap bars located in pci function 1, if enabled. table 20: pci_1 base address register and device decoder mappings (continued) pci base address register (bar) decoder 1 associated device sub-decoders GT-96100A advanced communication controller 60 revision 1.0 figure 3: cpu-side resource group decode function and example once a cpu resource group has been decoded, it must be subdecoded to determine which physical device should be accessed within that group. this decoding is controlled by the device low and high decode registers. the comparison works as follows: 1. bits 31:20 of the sysad address are compared against the relevant device low decode registers. the value of the sysad bits must be greater than or equal to the low decode value. this sets the lower boundary for the sub-decode region. 2. bits 31:20 of the sysad address are compared against the relevant device high decode registers. the value of the sysad bits must be less than or equal to this value. this sets the upper bound for the sub- decode region. 3. if all of the above are true, then the specific device is selected and an access to that device is performed. figure 4 illustrates the device decode process that occurs after the cpu resource group has been decoded. example: set up a sysad decode region that starts at 0xa.4000.0000 and is 512mbytes in length (0xa.4000.0000 to 0xa.5fff.ffff): if the sysad address is between the low and the high decode addresses, then the access is passed to the device unit for sub- decode. low processor decode reg high processor decode reg sysad address bits ge ge ge 23 22 21 20 le le le ge ge ge ge 27 26 25 24 le le le le eq eq eq eq 35 34 33 32 ge ge ge ge 31 30 29 28 le le le le low processor decode reg high processor decode reg sysad address bits 0 0 0 23 22 21 20 1 1 1 0 0 0 0 27 26 25 24 1 1 1 1 1 0 1 0 35 34 33 32 0 1 0 0 31 30 29 28 0 1 0 1 ?eq? equal to ?ge? greater or equal to ?le? less or equal to GT-96100A advanced communication controller revision 1.0 61 figure 4: device sub-decode function and example example: using the previous cpu decode example (0xa.4000.0000 to 0xa.5fff.ffff), place a device sub-decode in the first 384 meg (0xa.4000.0000 to 0xa.57ff.ffff). a match in the processor decoders forwards the address to the device sub-decoders processor decode region (512mbyte) 0xa.5fff.ffff device sub-decode region (384 meg) 0xa.4000.0000 0xa.57ff.ffff low processor decode reg high processor decode reg sysad address bits 0 0 0 23 22 21 20 1 1 1 0 0 0 0 27 26 25 24 1 1 1 1 1 0 1 0 35 34 33 32 0 1 0 0 31 30 29 28 0 1 0 1 low device decode reg high device decode reg 0 1 0 0 0 1 0 1 0 0 0 0 0 1 1 1 0 0 0 1 1 1 0 1 a match in the processor decoders forwards the address to the device subdecoders. low processor decode reg high processor decode reg sysad address bits ge ge ge 23 22 21 20 le le le ge ge ge ge 27 26 25 24 le le le le ge ge ge ge 31 30 29 28 le le le le low device decode reg high devicer decode reg ge ge ge ge le le le le ge ge ge ge le le le le ge ge ge le le le ge le ?eq? equal to ?ge? greater or equal to ?le? less or equal to GT-96100A advanced communication controller 62 revision 1.0 3.1.2 pci side decoding process decoding on the pci side starts with the pci address being compared with the values in the various base address registers. for example, the scs[1:0]* base address register sets the pci base address range in which the scs0* and scs1* signals are active (i.e., where dram banks 0 and 1 are located in pci space). once a resource group has been decoded by a bar, it must be subdecoded to determine which physical device should be accessed within that group. this decoding is controlled by the device low and high decode registers. note: these registers are the same ones used for cpu-side decoding. this means that the pci and sysad memory maps are coupled at the device decoders. address bits 31:20 (the bits compared by the device decoders) for any given device overlap in both the pci and sysad maps. the sub-decoding comparison works as follows: 1. bits 31:20 of the pci address are compared against bits the relevant device low decode registers. the value of the pci address bits must be greater than or equal to the low decode value. this sets the lower boundary for the sub-decode region. 2. bits 31:20 of the pci address are compared against the relevant device?s high decode registers. the value of the pci address bits must be less than or equal to this value. this sets the upper bound for the sub-decode region. 3. if all of the above are true, the specific device is selected and an access to that device is performed. figure 5: bank size register function example (16meg decode) 0 0 0 0 0 0 0 0 1 1 1 31 30 29 28 27 26 25 24 23 22 21 20 1 bank size reg pci address bits 1 1 1 1 1 1 1 19 18 17 16 15 14 13 12 1 = = = = = = = = x x x x x x x x x x x x '=' must match exactly 'x' don't care comparison against pci address GT-96100A advanced communication controller revision 1.0 63 3.2 disabling address decoders cpu interface address decoders can be disabled by setting the low decoder value higher than the high decoder value. device sub-decoder can be disabled by setting the low decoder value higher than the high decoder value. pci address decoders can be disabled by setting the bar?s corresponding bit in base address registers? enable to 1. 3.3 dma unit address decoding the idma controller uses the address mapping of the cpu interface. note: cpu interface address mapping to determine whether the source address is located in one of the sdram banks, device banks, pci_0 or pci_1. the same is true for destination address and next record address.dma address decoding is only up to address bit [31]. bits [35:32] of cpu address decoding registers are ignored. 3.4 address space decoding errors when the cpu tries to access an address from the sysad that is not supported, the GT-96100A: ? latches the address into the bus error address registers (offsets 0x70,0x78). ? issues a bus error (over syscmd[5]), if the access was a read access. ? issues an interrupt, if the access was a read or write access. this feature is useful during software debugging, when errant code can cause fetches from unsupported addresses. when sysad matches one of cpu interface address spaces, but misses the associated subdecoders, the gt- 96100a: ? issues a bus error (over syscmd[5]), if the access was a read access. ? sets the memout bit in the interrupt cause register. when a pci access hits in a base address register then misses in the associated subdecoders: ? random data is returned on a read and write data is discarded. ? latches the address into the address decode error register (offset 0x470). ? the memout bit in the interrupt cause register is also set. accesses that miss all of the GT-96100A bars result in no response at all from the GT-96100A. when a dma accesses an unmapped address, dmaout bit in the interrupt cause register is set. note: never program address space decoders to overlap. programming address space decoders to overlap results in unpredictable behavior. GT-96100A advanced communication controller 64 revision 1.0 3.5 default memory map the default cpu memory map that is valid following reset is shown in table 21 . the default pci map and bar sizing information is shown in table 22 and table 23 . table 21: cpu and device decoder default address mapping cpu decode range and size resource group device decode range and size device selected 0x0 to 0x0.00ff.ffff 16 megabytes scs[1:0]* 0x0 to 0x0.007f.ffff 8 megabytes scs0* 0x0.0080.0000 to 0x0.00ff.ffff 8 megabytes scs1* 0x0.0100.0000 to 0x0.01ff.ffff 16 megabytes scs[3:2]* 0x0.0100.0000 to 0x0.017f.ffff 8 megabytes scs2* 0x0.0180.0000 to 0x0.01ff.ffff 8 megabytes scs3* 0x0.1400.0000 to 0x0.1400.0fff 4 kbytes internal regis- ters no subdecode. access bridged directly to the gt- 96100a internal registers internal regis- ters 0x0.1000.0000 to 0x0.11ff.ffff 32 megabytes pci0 i/0 no subdecode. access bridged directly to pci i/0 space pci0 0x0.1200.0000 to 0x0.13ff.ffff 32 megabytes pci0 mem0 no subdecode. access bridged directly to pci memory space pci0 0x0.1c00.0000 to 0x0.1e1f.ffff 34 megabytes cs[2:0] 0x0.1c00.0000 to 0x0.1c7f.ffff 8 megabytes cs0* 0x0.1c80.0000 to 0x0.1cff.ffff 8 megabytes cs1* 0x0.1d00.0000 to 0x0.1dff.ffff 16 megabytes cs2* 0x0.1e00.0000 to 0x0.1e1f.ffff not accessible 0x0.1f00.0000 to 0x0.1fff.ffff 16 megabytes cs[3] and bootcs* 0x0.1f00.0000 to 0x0.1fbf.ffff 12 megabyte cs3* 0x0.1fc0.0000 to 0x0.1fff.ffff 4 megabytes bootcs* GT-96100A advanced communication controller revision 1.0 65 0x0.f200.0000 to 0x0.f3ff.ffff 32 megabytes pci0 mem1 no subdecode. access bridged directly to pci memory space pci0 0x0.2000.0000 to 0x0.21ff.ffff 32 megabytes pci1 i/0 no subdecode access bridged directly to pci i/ o space pci1 0x0.2200.0000 to 0x0.23ff.ffff 32 megabytes pci1 mem0 no subdecode. access bridged directly to pci memory space pci1 0x0.2400.0000 to 0x0.25ff.ffff 32 megabytes pci1 mem1 no subdecode. access bridged directly to pci memory space pci1 table 22: pci function 0 and device decoder default address mapping pci function 0 decode range and size resource group device decode range and size device selected 0x0 to 0x0.00ff.ffff 16 megabytes in memory space scs[1:0]* 0x0 to 0x0.007f.ffff 8 megabytes scs0* 0x0.0080.0000 to 0x0.00ff.ffff 8 megabytes scs1* 0x0.0100.0000 to 0x0.01ff.ffff 16 megabytes in memory space scs[3:2]* 0x0.0100.0000 to 0x0.017f.ffff 8 megabytes scs2* 0x0.0180.0000 to 0x0.01ff.ffff 8 megabytes scs3* 0x0.1400.0000 to 0x0.1400.0fff 4 kbytes in memory space internal regis- ters no subdecode internal regis- ters 0x0.1400.0000 to 0x0.1400.0fff 4 kbytes in i/o space internal regis- ters no subdecode. internal regis- ters table 21: cpu and device decoder default address mapping (continued) cpu decode range and size resource group device decode range and size device selected GT-96100A advanced communication controller 66 revision 1.0 0x0.1c00.0000 to 0x0.1dff.ffff 32 megabytes in memory space cs[2:0] 0x0.1c00.0000 to 0x0.1c7f.ffff 8 megabytes cs0* 0x0.1c80.0000 to 0x0.1cff.ffff 8 megabytes cs1* 0x0.1d00.0000 to 0x0.1dff.ffff 16 megabytes cs2* 0x0.1f00.0000 to 0x0.1fff.ffff 16 megabytes in memory space cs[3] and bootcs* 0x0.1f00.0000 to 0x0.1fbf.ffff 12 megabyte cs3* 0x0.1fc0.0000 to 0x0.1fff.ffff 4 megabytes bootcs* 0x0.1f00.000 to 0x0.1fff.ffff 16 megabytes (uses cs[3] and bootcs* size register) pci expansion rom no subdecode. this decoder is used only during pc bios initialization. cs3* table 23: pci function 1 (byte order swap) and device decoder default address mapping pci function 0 decode range and size resource group device decode range and size device selected 0x0 to 0x0.00ff.ffff 16 megabytes in memory space scs[1:0]* 0x0 to 0x0.007f.ffff 8 megabytes scs0* 0x0.0080.0000 to 0x0.00ff.ffff 8 megabytes scs1* 0x0.0100.0000 to 0x0.01ff.ffff 16 megabytes in memory space scs[3:2]* 0x0.0100.0000 to 0x0.017f.ffff 8 megabytes scs2* 0x0.0180.0000 to 0x0.01ff.ffff 8 megabytes scs3* table 22: pci function 0 and device decoder default address mapping (continued) pci function 0 decode range and size resource group device decode range and size device selected GT-96100A advanced communication controller revision 1.0 67 3.6 address remapping the GT-96100A supports address remapping on both the cpu interface and the pci interfaces. note: although the idma controllers use the cpu address decode registers, the source and destination dma addresses are never remapped. 3.6.1 cpu address remapping the resources that can be addressed by the cpu are the following: ? sdram banks (scs[1:0]*, scs[3:2]*) ? devices (cs[2:0]*, cs[3]* & bootcs*) ?pci_0 io ? pci_0 memory0/1 ?pci_1 io ? pci_1 memory0/1 note: pci_1 io and pci_1 memory0/1 are only addressable if the device is configured for both pci_0 and pci_1 on reset. each resource addressed by the cpu has a remap register associated with it. these registers are listed in section 4.10.2 ?cpu address decode registers? on page 87 . an address presented on the sysad bus by the cpu is decoded with the following steps: 1. address bits [35:21] are checked for a hit in the cpu decoders. 2. assuming there is a hit in the cpu decoders, the hit address will have bits 35:32 discarded. bits 20:0 are left unchanged. bits[31:21] are remapped as follows: going from the most significant bit (msb) to least significant bit (lsb) of the hit address bits [31:21], any bit found matching to its respective bit in the low decode register?s bits [10:0] will cause the according bit in the remap register to replace the original address bit. upon first mismatch, all remaining lsbs of address bits[31:21] are unchanged. 3. address bits [31:20] of the remapped address are checked to be a hit in the device decoders. 4. assuming there is a hit in the device decoders, the hit address will be transferred to the resource. see figure 6 outlining this address remapping procedure. 0x0.1f00.0000 to 0x0.1fff.ffff 16 megabytes in memory space cs[3]* and bootcs* 0x0.1f00.0000 to 0x0.1fbf.ffff 12 megabyte cs3* 0x0.1fc0.0000 to 0x0.1fff.ffff 4 megabytes bootcs* table 23: pci function 1 (byte order swap) and device decoder default address mapping (continued) pci function 0 decode range and size resource group device decode range and size device selected GT-96100A advanced communication controller 68 revision 1.0 figure 6: cpu address remapping to resources bits 35 - 32 are discarded. bits [20:0] are unchanged from the hit address. starting at the msb. each matching bit of [31:21] of the hit address and [10:0] of low decode are replace with bits in remap.all other bits are unchanged. remapped address remap register step 1. step 2. step 3. a match in the processor decoders forwards the address to remap register. step 4. a match in the sub- decoders forwards the address to the resource. address bits [35:21] are checked for a hit in the cpu decoders. low processor decode reg high processor decode reg sysad address bits ge ge ge 23 22 21 20 le le le ge ge ge ge 27 26 25 24 le le le le eq eq eq eq 35 34 33 32 ge ge ge ge 31 30 29 28 le le le le 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 3 2 1 0 ... 6 5 4 3 10 9 8 7 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 3 2 1 0 ... 2 1 0 low device decode reg high device decode reg ge ge ge le le le ge le ge ge ge ge le le le le ge ge ge ge le le le le GT-96100A advanced communication controller revision 1.0 69 3.6.2 writing to decode registers when a low decode register is written to, the least significant 11 bits are written to the associated remap regis- ter, simultaneously. when a remap register is written to, only its contents are affected. following reset, the default value of a remap register is equal to its associated low decode register bits [10:0]. unless a specific write operation to a remap register takes place, a 1:1 mapping is maintained. also, changing a low decode register?s contents automatically returns its associated space to a 1:1 mapping. this allows for backward software compatibility with other galileo technology devices such as the gt-64010a and the gt- 64011 core logic devices. 3.6.3 pci address remapping the pci slave interface has the ability to remap addresses of pci transactions to memory using pci remap regis- ters. there are seven registers for pci_0 and seven registers for pci_1, if implemented. these registers correspond to the following pci base address registers: ?scs[1:0]* ?scs[3:2]* ?cs[2:0]* ? cs[3]* & bootcs* ? swapped scs[1:0]* ? swapped scs[3:2]* ? swapped cs[3]* and bootcs* these registers are listed in the register section as part of pci internal registers, section 7.14.1 ?pci internal registers? on page 172 . the offsets for these registers are 0xc48 - 0xc64. each map register is 32-bits wide. each map register is 32-bits wide, where bits [12:0] are read only. when an address is presented on the pad lines, the address decoder in the pci slave compares the pci address to its base/size registers. if there is a hit in one of the seven base address registers listed above, then the address undergoes remapping in accordance to the right remap register in the non-masked address bits (by size register). an example of this is summarized in table 24 . table 24: pci address remapping example pci address 0x1d98.7654 scs[1:0]* bar 0x1f00.0000 scs[1:0]* size 0x03ff.ffff scs[1:0]* remap register 0x3f00.0000 remapped pci address presented to sdram 0x3d98.7654 GT-96100A advanced communication controller 70 revision 1.0 note: the size register is programmed to 0x03ff.ffff. this indicates that this bar requires a hit in the six msb (bits 31:26) bits of the pci address for their to be a hit in the bar. therefore, the pci address 0x1dxx.xxxx is a hit in a bar programmed to 0x1fxx.xxxx as bits 31-26 of both of these addresses is 0b0001.11. then according to the remap register, these same bit locations will be remapped to 6b111111. the rest of the pci address bits (i.e. [25:0]) remain unchanged. this means that the final pci slave address will be 0x3d987654. 3.6.4 writing to decode registers when a bar register is written to, the associated remap register is written to, simultaneously. when a remap reg- ister is written to, only its contents are affected. following reset, the default value of a remap register is equal to its associated bar decode register. unless a specific write operation to a remap register takes place, a 1:1 mapping is maintained. also, changing a bar register?s contents automatically returns its associated space to a 1:1 mapping. this allows for backward software compatibility with other galileo technology devices such as the gt-64010a and the gt-64011 core logic devices. 3.7 using the cpu pci override in default, the cpu interface supports 512mbyte pci memory address space (256mbyte on pci_0 mem0, 256mbyte on pci_0 mem1). if configured to both pci_0 and pci_1, it supports 512mbyte also on pci_1. the cpu pci override feature enables larger pci memory address space. the cpu configuration register includes four pci override bits - two bits per pci_0 and two bits per pci_1. each bit pair controls whether the pci window is 2gbyte, 1gbyte, or the default. setting the pci override bits are set to ?01?, and sysad bits[31:30] match bits [10:9] of the pci mem0 low decode address register, the transaction is directed to pci mem0. this effectively sets a 1gbyte window in the pci memory address space. note: if bits[31:30] do not match bits [10:9] of pci mem0 low decode address register, the address is com- pared against all other address decode registers. when pci override bits are set to ?10?, and sysad bit[31] matches bit [10] of the pci mem0 low decode address register, the transaction is directed to pci mem0. this effectively sets a 2gbyte window to pci. note: if bit[31] does not match bit [10] of pci mem0 low decode address register, the address is compared against all other address decode registers. if pci override bits are set to ?00? there is no pci override (default address decoding). GT-96100A advanced communication controller revision 1.0 71 note: when pci override is enabled, there is no address remapping from the cpu to the pci. 3.8 using the dma to pci bypass in default, the idma controller uses cpu interface address decoding. however, the idma controller supports direct access to pci bus, bypassing this address decoding. in each of the four dma channel control registers, there are six bits: ? two bits per source address. ? two bits per destination address. ? two bits per next record address. each bit pair controls whether the address should be directed to pci_0 memory space, to pci_1 memory space, or run through cpu address decoding. GT-96100A advanced communication controller 72 revision 1.0 4. cpu i nterface d escription the GT-96100A sysad bus interface allows the cpu to gain access to the GT-96100A?s internal registers, pci interface and the memory/device bus (ad bus). the sysad bus supports accesses from one to 32 bytes in length. the sysad bus on the GT-96100A is a slave-only interface. the GT-96100A will never master the sysad bus. 4.1 cpu interface signals the cpu interface incorporates the following signals: table 25: cpu interface signals signal type description sysad[63:0] - master address/data i/o transfers multiplexed address/data. syscmd[8:0] - master port command i/o transfers information about the access (read/write, size) and the data (good/bad, last word). sysadc[7:0] - master data check i/o an 8-bit bus containing parity for the sysad bus. sysadc is valid on data cycles only. validout* i indicates that the local master is driving valid address/data/command on the sysad bus. validin* o indicates that the GT-96100A is driving valid data/ command on the sysad bus. wrrdy* 1 1. there is no rdrdy* signal output from the GT-96100A. this signal should be tied low on the cpu as the GT-96100A is always re ady to accept a read command. o indicates that the GT-96100A is capable of accept- ing a write transaction up to eight 32-bit words in length. release* i indicates to the GT-96100A that the local master will not drive the sysad after the current clock cycle. for example, the local master is floating the sysad and syscmd bus for completion of a read. interrupt* o an ?or? of all the internal interrupt sources on the GT-96100A. scmatch i l2 cache tag ram hit indication. tcdoe* o l2 cache data ram output enable. asserted by the GT-96100A on l2 read hit. tctce* i l2 cache tag ram chip enable. sampled by the GT-96100A to identify l2 access. tcword[1:0] o l2 cache word index. driven by theGT-96100A dur- ing l2 read miss. GT-96100A advanced communication controller revision 1.0 73 the sysad bus is synchronous with respect to tclk and is locked with respect to the ad bus. the sysad bus may be asynchronous with respect to the pci bus or locked to the pci bus for lower synchronization latency. 4.2 sysad, sysadc, and syscmd buses the sysad and syscmd bus protocol implemented by the GT-96100A is completely compatible with the 64-bit orion bus protocol used by the idt r4xxx, r5000, and r7000 processors. the GT-96100A extends this protocol to support bursts less than four 64-bit words. these extensions can be used by dma engines on the sysad bus for more efficient use of the interface. the sysad[63:0] bus is a 64-bit multiplexed address/data bus. the local cpu drives address for a single cycle then either drives data (for a write) or floats the bus in anticipation of returned data (for a read.) sysadc[7:0] is valid during data cycles only. it provides parity information for data on the sysad bus. sysadc has the same timing as sysad. the syscmd[8:0] bus conveys the following information about the transaction: ? the direction (read/write). ? the size (byte, short, word, multi-word). ? the status of the data (good/bad/last.). syscmd is driven by the cpu (or other local master) during the address phase of a transaction (with direction/ size information) and for the duration of a write (with good/bad/last information.) the GT-96100A drives syscmd during the data phase of read transactions. the encodings for syscmd[8:0] are shown in the tables below. note: many encodings are not defined. these encodings are reserved and must not be used. a summary of bit usage is shown below. table 26: syscmd bit summary syscmd bit function syscmd[8] 0 = transaction information (read/write/size) 1 = data information (good/bad/last) syscmd[7] indicates last data/not last data during data cycles. note: must be 0 for address cycles. syscmd[6] 0 = read transaction during address cycles 1 = write transaction during address cycles note: must be 0 for data cycles. syscmd[5] indicates error status for data cycles. note: must be 0 for address cycles. GT-96100A advanced communication controller 74 revision 1.0 syscmd[4] 0 = check the data & check-bits during data cycles 1 = do not check data during data cycles note: must be 1 for address cycles. syscmd[3:0] encoded to indicate size of the transfer during address cycles. reserved during data cycles. table 27: address phase syscmd[8:0] encodings (driven by cpu) syscmd[8:0] encoding 1 command mnemonic command description 876543210 000011000 rdbyte read a single byte. 000011001 rdshort read 16 bits. 000011010 rdtribyte read 3 bytes. 000011011 rdword read 4 bytes (single word). 000011100 rd5byte read 5 bytes. 000011101 rd6byte read 6 bytes. 000011110 rd7byte read 7 bytes. 000011111 rddword read a double-word (64 bits). 000010xx0 rd4words not supported. 000010x01 rd8words read eight words (32 bytes) in a 4-dw burst. 00000 xxxx invalid reserved. 001011000 wrbyte write a single byte. 001011001 wrshort write 16 bits. 001011010 wrtribyte write 3 bytes. 001011011 wrword write 4 bytes (single word). 001011100 wr5byte read 5 bytes. 001011101 wr6byte read 6 bytes. 001011110 wr7byte read 7 bytes. 001011111 wr2words write a double word (8 bytes). 001010xx0 wr4words not supported. 001010x01 wr8words write eight words (32 bytes) in a 4-dw burst. table 26: syscmd bit summary (continued) syscmd bit function GT-96100A advanced communication controller revision 1.0 75 001100xxx nullreq null request command. 0011x1xxx invalid reserved. 1. ?x? denotes ?don?t care? but ?x? signals must be driven to a valid 0/1. table 28: read response syscmd[8:0] encodings (driven by the GT-96100A) syscmd[8:0] encoding 1 1. ?x? denotes ?don?t care? but ?x? signals are driven to a valid 0/1 by the GT-96100A . command mnemonic command description 876543210 1 1 0e0xxxx rd &chk indicates valid data and data-check-bit within a burst. e = 0 data is good e = 1 data is erroneous 1 1 0e1xxxx rd &nochk indicates valid data within a burst (no check-bit). e = 0 data is good e = 1 data is erroneous 1 0 0e0xxxx reod &chk indicates last valid data and data-checkbit within a burst. e = 0 data is good e = 1 data is erroneous 1 0 0e1xxxx reod &nochk indicates last valid data in a burst (no check-bit). e = 0 data is good e = 1 data is erroneous table 27: address phase syscmd[8:0] encodings (driven by cpu) (continued) syscmd[8:0] encoding 1 command mnemonic command description 876543210 GT-96100A advanced communication controller 76 revision 1.0 4.2.1 sysad read protocol sysad reads occur in three phases: note: if the read command requires parity, then check bits will be driven by the GT-96100A together with sysad data for every data transfer. the address phase for all transactions begins with the assertion of validout* to the GT-96100A. valid address and command information must be present on sysad and syscmd during this phase. release* must also be asserted to the GT-96100A to indicate that the local master is releasing mastership of the sysad/syscmd/ sysadc buses to the GT-96100A for completion of the read. validout* is deasserted at the end of the phase since the cpu is no longer driving information on sysad/syscmd. table 29: cpu write syscmd[8:0] encodings (driven by local master) syscmd[8:0] encoding 1 1. ?x? denotes ?don?t care? but ?x? signals are driven to a valid 0/1 by the GT-96100A . command mnemonic command description 876543210 1 1 1e0xxxx wd &chk indicates valid data and data-check-bit within a burst. e = 0 data is good e = 1 data is erroneous 1 1 1e1xxxx wd &nochk indicates valid data within a burst (no check-bit). e = 0 data is good e = 1 data is erroneous 1 0 1e0xxxx weod &chk indicates valid data and data-check-bit within a burst. e = 0 data is good e = 1 data is erroneous 1 0 1e1xxxx weod &nochk indicates last valid data in a burst (no check-bit). e = 0 data is good e = 1 data is erroneous table 30: sysad read phases phase description address address information is driven on the sysad bus and command information is driven on syscmd. mid burst-data the GT-96100A drives data on the sysad bus and a read response on syscmd. last burst-data the GT-96100A drives data on the sysad bus and a read end-of-data (reod) response on syscmd. GT-96100A advanced communication controller revision 1.0 77 for transactions longer than 64 bits, the mid-burst data phase is entered next. the GT-96100A: ? drives valid data on sysad. ? drives bits on sysadc[7:0] for parity. ? drives a valid read response (mnemonic = rd) on syscmd. ? assert validin* to qualify the sysad, sysadc, and syscmd buses (see figure 8 ). the GT-96100A transitions to the last-burst data phase on the last datum of the transfer. this state is differenti- ated by from the mid-burst state by the reod command driven on the syscmd bus. the last-burst data phase is also entered for the datum returned for a double word, single word, or sub-word, read. on the clock cycle following reod, the GT-96100A floats the sysad, sysadc, and syscmd buses, returning ownership to the cpu. figure 7: double word (8 bytes) read by cpu with parity check bits address phase single-burst phase local master must sample data here. wait states addr rddword data reod tclk validout* sysad[63:0] syscmd[8:0] release* validin* parity data sysadc[7:0] GT-96100A advanced communication controller 78 revision 1.0 figure 8: four word (16 bytes) burst read by cpu 4.2.2 sysad write protocol cpu writes occur in three phases: note: if the write command requires parity, then check bits are driven by the local master together with sysad data for every data transfer. the address phase for write transactions begins with the assertion of validout* to the GT-96100A. valid address and command information must be present on the sysad and syscmd busses during this phase. release* remains high for write transactions since the local master is not relinquishing ownership of the bus. validout* remains asserted throughout a write transaction as the cpu is always driving valid information on sysad/ sysadc/syscmd. for transactions longer than 64 bits, the mid-burst data write phase is entered next. the cpu drives valid data on sysad, a valid write command (mnemonic = wd) on syscmd (see figure 9 ). table 31: sysad write phases phase description address address information is driven on the sysad bus and command information is driven on syscmd. mid-burst write data the local master drives data on the sysad bus, possibly parity data on sysadc[7:0], and a write command (mnemonic = wd) on syscmd. last-burst write data the local master drives data on the sysad bus and a write end-of-data (weod) command on syscmd. addr rdword data 1 rd data 2 reod wait state. tclk validout* sysad[63:0] syscmd[8:0] release* validin* address phase last-burst phase mid-burst data read phase local master must sample data here. local master must sample data here. GT-96100A advanced communication controller revision 1.0 79 figure 9: cpu four word burst write the GT-96100A transitions to the last-burst write data phase on the last datum of the transfer. this state is differ- entiated from the mid-burst state by the weod command driven on the syscmd bus. the last-burst data phase is also entered for the datum written for a single word, or sub-word, write. on the clock cycle following weod, the GT-96100A returns to the idle state. note: cpu writes cannot be issued as long as wrrdy* is deasserted (high). if wrrdy* is high and an cpu write is attempted, data from previous write cycles may be corrupted (see section 4.3 ?operation of wrrdy* and the internal write posting queues? on page 79 .) all mips compliant processors follow this protocol. only dma engines on the sysad bus need to be concerned with sampling wrrdy* before initiating a write. 4.3 operation of wrrdy* and the internal write posting queues the GT-96100A?s cpu interface includes a write posting queue that absorbs local cpu writes at zero wait-states. this is required per the mips sysad bus write protocol. the write posting queue has four address entries and eight 64-bit data entries. the GT-96100A signals if there is room in the cpu write posting queue by asserting wrrdy*. if wrrdy* is asserted, the cpu may issue a write of up to eight words or four double words. mips compliant processors such as the r4xxx/r5000/r7000 sample wrrdy* automatically before issuing a write. 4.4 cpu write modes and write patterns supported the GT-96100A supports both pipelined and r4xxx/r5000/r7000 compatible write modes (with two dead cycles between consecutive writes). the default mode is pipelined. however, the r4xxx mode can be selected in the cpu interface configuration register. the cpu interface supports only dddd and dxdxdxdx write patterns. one of these two write patterns must be selected via the cpu serial initialization bitstream during the cpu reset process. bit 16 of the cpu interface configuration register (0x000) must be programmed according to the write pattern programming of the cpu. note: in the above explanation, ?d? represents data and ?x? is a wait state. addr wr4word data 1&2 data 3&4 weod tclk validout* wrrdy* s ysad[63:0] s yscmd[8:0] release* validin* address phase last-burst phase mid-burst data write phase GT-96100A advanced communication controller 80 revision 1.0 4.5 cpu interface endianess the GT-96100A provides the capability to swap the data transferred to or from the internal registers and to or from the pci interface. note: data written to or from the memory controller is never swapped. the GT-96100A interface endianess to the cpu is programmed on reset by sampling the interrupt* pin, see section 22. ?reset configuration? on page 452 . the setting of this pin programs the endianess bit in the cpu configuration register at 0x000. when accessing the internal registers, the endianess of the data will be deter- mined by the interrupt* pin?s setting. note: if set to big endian, data is swapped. the setting of the byteswap bit in the pci internal command register, bit 0 of 0xc00, determines how data transactions from the cpu to/from pci are handled along with the setting of bit 12 in the cpu configuration register, 0x000. both of these bits are set to the same value as the pin strapping of the interrupt*, but can be re- programmed after reset. the setting of mbyteswap bit and mwordswap bit in the pci internal command register, determines how data transactions from the cpu to or from the pci are handled along with the setting of the endianess bit in the cpu configuration register. both mbyteswap and endianess bits are set to the same value as the pin strapping of the interrupt* (resulting pci interface working in little-endian mode). these bits can be re-programmed after reset. 4.6 burst order the GT-96100A supports only the sub-block ordered bursts used by orion mips processors. sub-block ordered bursts are optimized for the burst patterns used by most sdrams. 4.7 mips l2 cache support the GT-96100A supports second level cache placed on the sysad bus. it does not include l2 cache controller, but it supports l2 required signaling, as defined in the r5000 specification. GT-96100A samples the scmatch signal. if a cpu access hits the l2 cache line (tag ram asserts scmatch sig- nal), the GT-96100A ignores the transaction, enabling the cpu to complete the transaction against l2 cache. if the cpu initiates a block read transaction with sctce* asserted (indicating a l2 read request), and scmatch is asserted two cycles after issue cycle (indicating a l2 hit), the GT-96100A ignores the transaction, but keeps scdoe* asserted, enabling l2 data ram drive read data on the sysad bus. scdoe[1:0] word index is driven by the r5000 l2 cache controller. in case cache miss (scmatch deasserted two cycles after block read issue cycle), the GT-96100A responds to the transaction. it also deasserts scdoe* preventing l2 data ram from driving the bus, and drives scword[1:0] for the l2 data ram to load the data that the GT-96100A returns to cpu. an example of l2 read miss is shown in figure 10 . GT-96100A advanced communication controller revision 1.0 81 figure 10: r5000 l2 read miss example 4.8 multiple GT-96100A support up to four GT-96100A devices can be connected to the cpu system interface without the need for any glue logic. this capability increases the address space and adds significant flexibility for system design. enable multiple GT-96100A devices by sampling the value of dadr[10] on reset, see section 22. ?reset con- figuration? on page 452 . if this pin is sampled high, multiple GT-96100A devices are enabled. the value of dadr[10] sampled on reset will also set bit 18, multigt, of the cpu configuration register at 0x000. this bit is programmable after reset. note: this pin must be tied low if there is only one GT-96100A device. if multiple GT-96100A devices are enabled, the values sampled on ready* and cstiming* determine the id of the particular GT-96100A device, as shown in table 32 . this sampled values also program the multigtact bits [1:0] in the multigtid register, 0x120. these bits are programmable after reset. table 32: pin strapping the GT-96100A id pin configuration function ready*, cstiming* multi-GT-96100A address id 00 - 01- 10 - 11- gt responds to sysad[26,25]=00 gt responds to sysad[26,25]= 01 gt responds to sysad[26,25]=10 gt responds to sysad[26,25]= 11 note: boot GT-96100A must be programmed to 11 addr read d10 d11 d12 d13 i0 i1 i2 i3 i0 i1 i2 i3 sysclk sysad[63:0] syscmd[8:0] validout* release* sctce* scmatch validin* scdoe* scword[1:0] GT-96100A advanced communication controller 82 revision 1.0 4.8.1 hardware connections when multiple GT-96100A devices are enabled, the wrrdy*, validin*, and scdoe* signals have slightly differ- ent functionality versus when only one GT-96100A is enabled. 4.8.2 multigt bit in the cpu configuration register when the multigt bit is set, the cpu interface address decoding reduces to: ? if (sysad[26:25] == id) and (it's a write), the access is directed to the internal space of the cpu interface registers. bits[11:0] define the specific register offset. ? if (sysad[26:25] == id) and (it's a read) and (sysad[27] == 0), the access is directed to the internal space of the cpu interface registers. bits[11:0] define the specific register offset. ? if (sysad[26:25] == id) and (it's a read) and (sysad[27] == 1), the access is directed to bootcs*. since 0x0.1fc0.0000 implies sysad[26:25] == 3, the gt 96100a holding the boot device should be strapped to id = 3. note: as long as multigt bit is set, there is no access to pci, sdram and devices and dma internal regis- ters. access is available only to the cpu interface internal registers and to boot rom. ? when the multigt bit is cleared, the cpu interface resumes normal address decoding. note: after the multigt bit is cleared, wrready*,validin*, and scdoe* signals still operate as sustained 3-state (sts) outputs. table 33: wrrdy*, validin*, and scdoe* signal multiple GT-96100A functionality signal multiple GT-96100A functionality wrrdy* an open-source output requiring a 4.7 kohm pull-down resistor. all wrrdy* outputs from the GT-96100A devices must be tied together to drive the cpu wrrdy* input. wrrdy* is driven low for one cycle before floating the output. validin* an open-drain output requiring a 4.7 kohm pull-up resistor. all validin* outputs from the gt- 96100a devices must be tied together to drive the cpu validin* input. validin* is driven high for one cycle before floating the output. scdoe* an open-source output requiring a 4.7 kohm pull-down resistor. all scdoe* outputs from the GT-96100A devices must be tied together to drive the cpu and secondary cache inputs. scdoe* is driven low for one cycle before floating the outputs. GT-96100A advanced communication controller revision 1.0 83 4.8.3 initializing a multiple GT-96100A system this section contains an example of connecting two GT-96100A devices to the same cpu. in actuality, it is pos- sible to connect up to four GT-96100A devices to the same cpu. use the following procedure for initializing a system with two GT-96100A devices attached to the same cpu. note: assuming that the two GT-96100A devices are called gt-1 and gt-2, respectively; both devices have dadr[10] pulled to vcc (enabling multigt mode). gt-1 has ready* and cstiming* tied to 11 (boot GT-96100A). gt-2 has ready* and cstiming* tied to 00. gt-1 has the bootrom. both GT-96100A devices will now resume normal operation with usual address decoding. note: in multigt mode, the GT-96100A does not support address mismatch in the cpu interface decode. in other words, if the cpu attempts a read of which the address is not mapped in any of the gt- 96100a devices in the system, validin* is not returned to the cpu and the system will halt. 4.8.4 multi-gt restrictions 1. due to system interface loading, maximum operating frequency will decrease as the number of gt- 96100a devices increase. 2. when multi-gt support is enabled and if the cpu and GT-96100A are in pipeline writes mode (bit 11, writemode, in the cpu interface configuration register - 0x0, reset to 0), a contention for one clock cycle on the wrrdy* signal may occur. as a result, only r4000 mode (no pipeline writes - 1 wait state between transactions) is allowed when multi-gt support is enabled. table 34: initializing a multiple GT-96100A system initialization steps description 1. access gt-1's bootrom and reconfigure gt-2's cpu interface address space registers. after reset, the processor executes from the bootrom on gt-1 because the address on sysad is 0x0.1fcx.xxxx where sysad[27:25] = 111 and it's a read cycle. registers on gt-1 are accessible via address sysad[26:25]=11, [20:0]=offset]. registers on gt-2 are accessible via address [sysad[26:25]=00, [20:0]=offset]. 2. access gt-1's bootrom and reconfigure gt-1's cpu interface address space registers. reconfigures also, the internal space address decode register, so that later (once multi-gt mode is disabled) the user can distinguish between internal accesses to gt-1 or gt-2. 3. lower gt-2 bootcs* high decode register below 0x0.1fcx.xxxx (i.e. 0x0.1fbx.xxxx). causes gt-2 to ignore accesses to 0x0.1fcx.xxxx once taken out of multigt mode. further, the address mapping of register and memory space in the GT-96100A and on their interfaces must be unique. in other words, the four pci address ranges, two sdram ranges, i/o space, and internal GT-96100A register spaces of both system con- trollers must be different. 4. clear gt-2 multi-gt mode bit. 5. clear gt-1 multi-gt mode bit. GT-96100A advanced communication controller 84 revision 1.0 4.9 cpu interface restrictions 1. the GT-96100A does not support access of more than 4 bytes to internal space. 4.10 cpu interface control registers table 35: cpu interface register map description offset page number cpu configuration cpu interface configuration 0x000 page 85 multi-gt register 0x120 page 87 cpu address decode scs[1:0]* low decode address 0x008 page 87 scs[1:0]* high decode address 0x010 page 87 scs[3:2]* low decode address 0x018 page 88 scs[3:2]* high decode address 0x020 page 88 cs[2:0]* low decode address 0x028 page 88 cs[2:0]* high decode address 0x030 page 88 cs[3]* & boot cs* low decode address 0x038 page 88 cs[3]* & boot cs* high decode address 0x040 page 89 pci_0 i/o low decode address 0x048 page 89 pci_0 i/o high decode address 0x050 page 89 pci_0 memory 0 low decode address 0x058 page 89 pci_0 memory 0 high decode address 0x060 page 89 pci_0 memory 1 low decode address 0x080 page 90 pci_0 memory 1 high decode address 0x088 page 91 pci_1 i/o low decode address 0x090 page 90 pci_1 i/o high decode address 0x098 page 90 pci_1 memory 0 low decode address 0x0a0 page 90 pci_1 memory 0 high decode address 0x0a8 page 91 pci_1 memory 1 low decode address 0x0b0 page 91 pci_1 memory 1 high decode address 0x0b8 page 91 internal space decode 0x068 page 91 GT-96100A advanced communication controller revision 1.0 85 4.10.1 cpu configuration registers scs[1:0]* address remap 0x0d0 page 91 scs[3:2]* address remap 0x0d8 page 92 cpu address decode (continued) cs[2:0]* remap 0x0e0 page 92 cs[3]* & boot cs* remap 0x0e8 page 92 pci_0 i/o remap 0x0f0 page 92 pci_0 memory 0 remap 0x0f8 page 92 pci_0 memory 1 remap 0x100 page 93 pci_1 i/o remap 0x108 page 93 pci_1 memory 0 remap 0x110 page 93 pci_1 memory 1 remap 0x118 page 93 cpu sync barrier pci_0 sync barrier virtual register 0x0c0 page 94 pci_1 sync barrier virtual register 0x0c8 page 94 table 36: cpu interface configuration, offset: 0x000 bits field name function initial value 8:0 reserved cache operation mapping indicates which address bits the gt? 64012 uses for cache flush and cache invalidate operations. bits [8:0] corre- spond to sysad[35:27]. must be 0 0x0 9 reserved secondary cache support 0 - gt?64012 not present 1 - gt?64012 present must be 0 0x0 10 reserved reserved must be 0 0x0 table 35: cpu interface register map (continued) description offset page number GT-96100A advanced communication controller 86 revision 1.0 11 writemode write mode 0 - pipelined writes mode 1 - r4000 mode there must be at least two dead-cycles minimum between consecutive address- phase. 0x0 12 endianess byte orientation 0 - big endian 1 - little endian note: affects only the internal registers and the pci configuration data register. sampled at reset via the interrupt* pin. 13 reserved must be 0. 0x0 14 r5kl2_present second level cache present 0 - r5kl2 not present 1 - r5kl2 present 0x0 15 external_hit_delay register second level cache scmatch sig- nal 1 . 0 - not sampled inside the GT-96100A. 1 - sampled inside the GT-96100A. 0x0 16 cpu writerate cpu data write rate 0 - dxdxdxdx 1 - dddd 0x0 17 stop_retry relevant only if pci retry was enabled (dadr[6] was sampled 0 at reset). 0 - continue to retry all pci transactions targeted to the controller?s pci slave 1 - stop retry of pci transactions 0x0 18 multigt multiple GT-96100A support 0 - not supported 1 - supported sampled at reset via the dadr[10] pin 19 sysadcvalid GT-96100A to cpu sysadc connection 0 - not connected (no parity) 1 - connected 0x0 21:20 pci_0_override 00 - normal address decoding 01 - 1gbyte pci_0 mem0 space 10 - 2gbyte pci_0 mem0 space 11 - reserved 0x0 23:22 reserved 0x0 table 36: cpu interface configuration, offset: 0x000 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 87 4.10.2 cpu address decode registers 25:24 pci_1_override 00 - normal address decoding 01 - 1gbyte pci_1 mem0 space 10 - 2gbyte pci_1 mem0 space 11 - reserved 0x0 31:26 reserved 0x0 1. tagrams used with l2/l3 cache output the scmatch signal registered. if for some reason, the tagram in use outputs the scmatch signal non-registered, this bit must be set to 1 to maintain timing relationship between the cache and the GT-96100A. table 37: multi-gt register, offset: 0x120 bits field name function initial value 1:0 multigtact multi-gt activity bits these bits represent the id to which the GT-96100A responds with activity. value sampled at reset on ready* and cstim- ing*. 31:2 reserved 0x0 table 38: scs[1:0]* low decode address, offset: 0x008 bits field name function initial value 14:0 low sdram banks 1 and 0 are accessed when the decoded addresses are between low and high. 0x0000 31:15 reserved 0x0 table 39: scs[1:0]* high decode address, offset: 0x010 bits field name function initial value 10:0 high sdram banks 1 and 0 are accessed when the decoded addresses are between low and high. 0x07 31:11 reserved 0x0 table 36: cpu interface configuration, offset: 0x000 (continued) bits field name function initial value GT-96100A advanced communication controller 88 revision 1.0 table 40: scs[3:2]* low decode address, offset: 0x018 bits field name function initial value 14:0 low sdram banks 3 and 2 are accessed when the decoded addresses are between low and high. 0x0008 31:15 reserved 0x0 table 41: scs[3:2]* high decode address, offset: 0x020 bits field name function initial value 10:0 high sdram banks 3 and 2 are accessed when the decoded addresses are between low and high. 0x0f 31:11 reserved 0x0 table 42: cs[2:0]* low decode address, offset: 0x028 bits field name function initial value 14:0 low device banks 2, 1, and 0 are accessed when the decoded addresses are between low and high. 0x00e0 31:15 reserved 0x0 table 43: cs[2:0]* high decode address, offset: 0x030 bits field name function initial value 10:0 high device banks 2, 1, and 0 are accessed when the decoded addresses are between low and high. 0xf0 31:11 reserved 0x0 table 44: cs[3]* & boot cs* low decode address, offset: 0x038 bits field name function initial value 14:0 low device bank 3 and the boot bank are accessed when the decoded addresses are between low and high. 0x00f8 31:15 reserved 0x0 GT-96100A advanced communication controller revision 1.0 89 table 45: cs[3]* & boot cs* high decode address, offset: 0x040 bits field name function initial value 10:0 high device bank 3 and the boot bank are accessed when the decoded addresses are between low and high. 0xff 31:11 reserved 0x0 table 46: pci_0 i/o low decode address, offset: 0x048 bits field name function initial value 14:0 low the pci_0 i/o address space is accessed when the decoded addresses are between low and high. 0x0080 31:15 reserved 0x0 table 47: pci_0 i/o high decode address, offset: 0x050 bits field name function initial value 10:0 high the pci_0 i/o address space is accessed when the decoded addresses are between low and high. 0x8f 31:11 reserved 0x0 table 48: pci_0 memory 0 low decode address, offset: 0x058 bits field name function initial value 14:0 low the pci_0 memory address space is accessed when the decoded addresses are between low and high. 0x0090 31:15 reserved 0x0 table 49: pci_0 memory 0 high decode address, offset: 0x060 bits field name function initial value 10:0 high the pci_0 memory address space is accessed when the decoded addresses are between low and high. 0x9f 31:11 reserved 0x0 GT-96100A advanced communication controller 90 revision 1.0 table 50: pci_0 memory 1 low decode address, offset: 0x080 bits field name function initial value 14:0 low the pci_0 memory address space is accessed when the decoded addresses are between low and high. 0x0790 31:15 reserved 0x0 table 51: pci_0 memory 1 high decode address, offset: 0x088 bits field name function initial value 10:0 high the pci_0 memory address space is accessed when the decoded addresses are between low and high. 0x79f 31:11 reserved 0x0 table 52: pci_1 i/o low decode address, offset: 0x090 bits field name function initial value 14:0 low the pci_1 i/o address space is accessed when the decoded addresses are between low and high. 0x0100 31:15 reserved 0x0 table 53: pci_1 i/o high decode address, offset: 0x098 bits field name function initial value 10:0 high the pci_1 i/o address space is accessed when the decoded addresses are between low and high. 0x10f 31:11 reserved 0x0 table 54: pci_1 memory 0 low decode address, offset: 0x0a0 bits field name function initial value 14:0 low the pci_1 memory address space is accessed when the decoded addresses are between low and high. 0x0110 31:15 reserved 0x0 GT-96100A advanced communication controller revision 1.0 91 table 55: pci_1 memory 0 high decode address, offset: 0x0a8 bits field name function initial value 10:0 high the pci_1 memory address space will be accessed when the decoded addresses are between low and high. 0x11f 31:11 reserved 0x0 table 56: pci_1 memory 1 low decode address, offset: 0x0b0 bits field name function initial value 14:0 low the pci_1 memory address space is accessed when the decoded addresses are between low and high. 0x0120 31:15 reserved 0x0 table 57: pci_1 memory 1 high decode address, offset: 0x0b8 bits field name function initial value 10:0 high the pci_1 memory address space is accessed when the decoded addresses are between low and high. 0x12f 31:11 reserved 0x0 table 58: internal space decode, offset: 0x068 bits field name function initial value 14:0 intdecode registers inside the GT-96100A are accessed when sysad bits 35:21 match the value programmed in bits 14:0. 0x00a0 31:15 reserved 0x0 table 59: scs[1:0]* address remap, offset: 0x0d0 bits field name function initial value 10:0 scs[1:0]*_remap cpu address remap to resources for sdram 0 region. 0x0 31:11 reserved 0x0 GT-96100A advanced communication controller 92 revision 1.0 table 60: scs[3:2]* address remap, offset: 0x0d8 bits field name function initial value 10:0 scs[3:2]*_remap cpu address remap to resources of sdram 1 region. 0x008 31:11 reserved 0x0 table 61: cs[2:0]* address remap, offset: 0x0e0 bits field name function initial value 10:0 cs[2:0]*_remap cpu address remap to resources of device 0 region. 0x0e0 31:11 reserved 0x0 table 62: cs[3]* & boot cs* address remap, offset: 0x0e8 bits field name function initial value 10:0 cs[3]*_&_ boot cs*_remap cpu address remap to resources of device 1 region. 0x0f8 31:11 reserved 0x0 table 63: pci_0 io address remap, offset: 0x0f0 bits field name function initial value 10:0 pci_0_io_remap cpu address remap to resources of pci_0 io region. 0x080 31:11 reserved 0x0 table 64: pci_0 memory 0 address remap, offset: 0x0f8 bits field name function initial value 10:0 pci_0_mem0_ remap cpu address remap to resources of pci_0 memory 0 region. 0x090 31:11 reserved 0x0 GT-96100A advanced communication controller revision 1.0 93 table 65: pci_0 memory 1 address remap, offset: 0x100 bits field name function initial value 10:0 pci_0_mem1_ remap cpu address remap to resources of pci_0 memory 1 region. 0x790 31:11 reserved 0x0 table 66: pci_1 io address remap, offset: 0x108 bits field name function initial value 10:0 pci_1_io_remap cpu address remap to resources of pci_1 io region. 0x100 31:11 reserved 0x0 table 67: pci_1 memory 0 address remap, offset: 0x110 bits field name function initial value 10:0 pci_1_mem0_ remap cpu address remap to resources of pci_1 memory 0 region. 0x110 31:11 reserved 0x0 table 68: pci_1 memory 1 address remap, offset: 0x118 bits field name function initial value 10:0 pci_1_mem1_ remap cpu address remap to resources of pci_1 memory 1 region. 0x120 31:11 reserved 0x0 GT-96100A advanced communication controller 94 revision 1.0 4.10.3 cpu sync barrier table 69: pci_0 sync barrier virtual register, offset: 0x0c0 bits field name function initial value 31:0 syncbarrier_0 a cpu read from this register creates a synchronization barrier cycle. when vali- din* is returned to the cpu, both of the pci_0 slave fifos are guaranteed to be empty. the read data returned to the cpu is random and should be ignored. this register is read only. 0x0 table 70: pci_1 sync barrier virtual register, offset: 0x0c8 bits field name function initial value 31:0 syncbarrier_1 a cpu read from this register creates a synchronization barrier cycle. when vali- din* is returned to the cpu, both of the pci_1 slave fifos are guaranteed to be empty. the read data returned to the cpu is random and should be ignored. this register is read only. 0x0 GT-96100A advanced communication controller revision 1.0 95 5. m emory c ontroller the GT-96100A?s memory controller consists of an integrated sdram controller and a device controller. the sdram controller has a 15-bit address bus (dadr[12:0],banksel[1:0]) and shares the 64-bit address/data (ad) bus for data transfers. the device controller uses the 64-bit muxed ad bus for both address and data transfers. all memory and i/o devices in a GT-96100A system are connected to the ad bus (the sysad bus is used prima- rily as a point-to-point connection between the cpu and the GT-96100A system.) the memory controller only master reads and writes transactions to sdram or devices. it receives the instructions for these transactions from the cpu, idma controller, or a pci device on the pci interface. note: a device may not master transactions via the GT-96100A?s memory controller. the GT-96100A?s memory controller supports both 32 or 64-bit sdram as well as 8-, 16-, 32-, and 64-bit devices. note: whenever this datasheet refers to 64-bit sdram, it means 64-bits of data plus eight additional bits for ecc. the GT-96100A supports two arbitration schemes for memory controller requests. the default arbitration is shown in figure 11 , while a modified arbitration scheme is shown in figure 12 . GT-96100A advanced communication controller 96 revision 1.0 figure 11: memory controller default arbitration uma toggle cpu comm / idma refresh toggle pci 1 pci 0 note: only if the memory controller is idle, a low priority uma request is granted. GT-96100A advanced communication controller revision 1.0 97 figure 12: memory controller modified arbitration the modified arbitration reduces the latency associated with cpu memory read transactions. 1 1. programming the memory controller?s arbitration mode is done using bit 10 of the sdram burst mode register (see table 107, ?sdram burst mode, offset: 0x478,? on page 135 ). cpu (*) toggle cpu comm / idma refresh toggle pci 1 pci 0 note: only if the memory controller is idle, a low priority uma request is granted. GT-96100A advanced communication controller 98 revision 1.0 5.1 sdram controller the sdram controller supports up to four banks of sdrams. the sdram configuration register (0x448) contains configuration information which is valid for the four banks. various access parameters can be programmed on a per bank basis as each bank has its own parameters register (0x44c - 0x458). the supported address depth of the sdram can vary for each bank, depending on whether 16, 64, 128 or 256mbit sdrams are used (see section 5.2 ?connecting the address bus to the sdram? on page 106 for more information). up to 256 mbytes can be addressed by each scs for a total sdram address space of 512 mbytes by the GT-96100A system. 5.1.1 sdram configuration register (0x448) the sdram configuration register contains parameters which are used for all of the sdram banks used with the GT-96100A. 5.1.1.1 refresh rates the GT-96100A implements standard scas before sras refreshing. the refresh rate for the sdram banks is programmable using the refintcnt field in the sdram configuration register, see table 105 . for example, the default value of refintcnt is 0x200. if tclk is 100 mhz, than a refresh sequence will occur every 5us. this is derived from 100mhz (=10ns) * 0x200 (512d) = 5.12us. every instance that the refresh counter in the GT-96100A device reaches its terminal count, a refresh request is sent to the memory controller. this request enters the arbiter. once the ad bus is idle and the last sdram or device transaction has finished, the refresh cycle begins. note: if a uma transaction is being serviced, the external sdram master is responsible for refreshing the sdram. see section 5.6 ?unified memory architecture (uma) support? on page 113 . 5.1.1.2 non-staggered and staggered refresh non-staggered or staggered refresh for each bank can be programmed according to stagref in the sdram con- figuration register. in non-staggered refresh, scs[3:0]* and sras* and scas* simultaneously asserts refreshing all banks at the same time as shown in figure 13 . if the sdram controller is programmed to perform staggered refresh (default), scs[3:0]* will not simulta- neously assert low together with sras*, following the low-going scas*. rather, scs[0]* will first go low for 1 cycle, followed by scs[1]* on the next tclk, and so on. after the last scs[3]* has asserted low for 1 cycle, scas* and sras* will go high again. staggered refresh is useful for load balancing, shown in figure 14 . GT-96100A advanced communication controller revision 1.0 99 figure 13: non-staggered refresh waveform figure 14: staggered refresh waveform 5.1.1.3 read modify write enable/ecc the GT-96100A supports error checking and correction of 64-bit wide sdrams. note: see section 6. ?data integrity? on page 143 for more information about ecc. for 64-bit sdrams with ecc enabled, ecc is generated and written to the adp[7:0] lines on 64-bit writes dur- ing the same cycle that the data is written. bit 15 enables or disables read modify write protocol to sdram . if ecc is enabled in any of the dram banks, this bit must be set to 1 to enable read modify write. ecc checking and generation requires a 72-bit dimm to store the ecc information. in order to generate the ecc on partial writes, the current ecc bits must first be read and then modified during the partial write. the protocol for the read modify write transaction is as follows: 1. read the existing data and ecc information. on this read, all sdqm* lines are asserted (low). this means that the be (byte enable) for the ecc byte can be connected to any of the sdqm[7:0]* outputs. the ecc data is read on the adp[7:0] inputs. 2. modify the ecc information based on the data that is to be written. the modification of the ecc byte is done in the GT-96100A system. tclk scs[3:0]* sras* 0 f f scas* tclk scs[3:0]* sras* b d e ff 7 scas* GT-96100A advanced communication controller 100 revision 1.0 3. write the new data and new ecc byte. figure 15 illustrates the procedure used to generate ecc in a partial write to sdram. figure 15: read modify write transaction by the sdram controller 5.1.2 duplicating signals some systems require using duplicate signals due to loading requirements. the following sections outlines which signals can be duplicated by setting the appropriate bit in the sdram configuration register. 5.1.2.1 duplicating sdram control lines sras*, scas*, and dwr* are the control lines for sdram. these signals can be duplicated on different pins for loading considerations. setting bit 19 to 0 means these sras*, scas*, and dwr* signals are not duplicated on other pins (default). setting bit 19 to 1 means sras*, scas*, and dwr* signals are duplicated on dmareq[0]*/mreq*, dmareq[3]*, and bypsoe*/mgnt, respectively. these pins are no longer usable as dmareq[0]*/mreq*, dmareq[3]*, and mgnt*/bypoe* when bit 19 is set to 1. regardless of the pin strapping of dadr[7] sampled on reset (uma enable), when bit 19 is set to 1, the duplication of sras*, scas*, and dwr* on the dmareq[0]*, dmareq[3]*, and bypsoe* pins takes priority over setting dmareq[0]* to mreq* and byp- soe* to mgnt. 2. modify data and ecc byte in the GT-96100A device adp[7:0] . . . x8 sdram #1 x8 sdram #2 x8 sdram #7 x8 sdram #8 x8 sdram #9 x72 sdram sdqm[0]* asserted sdqm[1]* asserted sdqm[6]* asserted sdqm[7]* asserted 1. read all data and ecc bits 0 0 1 0 1 1 1 0 existing ecc byte 1 0 1 1 0 0 1 0 adp[7:0] sdram ecc . . . x8 sdram #1 x8 sdram #2 x8 sdram #7 x8 sdram #8 x8 sdram #9 x72 sdram sdqm[0]* asserted sdqm[1]* asserted sdqm[6]* asserted sdqm[7]* asserted 3. write new data and modified ecc byte sdqm[x]* asserted sdqm[x]* asserted data[7:0] data[15:8] data[55:48] data[63:56] data[7:0] new data[15:8] new data[55:48] existing data[63:56] existing new ecc byte GT-96100A advanced communication controller revision 1.0 101 5.1.2.2 duplicating dadr[11] and banksel[1] on dmareq[2:1]* dadr[11] and banksel[1] are used for 64/128/256 mbit sdram. these signals can be duplicated on different pins for loading considerations. setting bit 20 to 0 means these pins are not duplicated on other pins (default). setting bit 20 to 1 means dadr[11] and banksel[1] signals are duplicated on dmareq[2]* and dmareq[1]*, respectively. these pins are no longer usable as dmareq[2]* and dmareq[1]* when bit 20 is set to 1. note: if ecc is implemented in the system, adp[5:4] cannot be used as dadr[11] and banksel[1]. there- fore, to use dadr[11] and banksel[1], program bit 20 to 1 and use dmareq[2:1]* as dadr[11] and banksel[1]. 5.1.2.3 dma end of transfer pins functionality the idma controllers use the end of transfer pins to give an external device the ability to terminate a current dma transfer. see table 236 for more information about this feature. bit 21 controls the function of dmareq[3]*. setting this bit to 0 means dmareq[3]* functions as dma request for channel 3. setting this bit to 1 means dmareq3* functions as end of transfer for channel 0, eot0. likewise, setting bit 22 to 0 means ready* functions as ready. and, setting this bit to 1 means ready* functions as end of transfer for channel 1, eot[1]. table 71: dmareq*, ready* and bypsoe* functionality primary signal name secondary signal name (programmed on reset) bit 19 = 1 bit 20 = 1 bit 21 = 1 bit 22 = 1 dmareq[0]* mreq* sras* dmareq[1]* banksel[1] dmareq[2]* dadr[11] dmareq[3]* scas* eot[0] ready* eot[1] bypsoe* mgnt* dwr* GT-96100A advanced communication controller 102 revision 1.0 5.1.2.4 multiplexing dadr[12] if any of the sdram banks is configured to 256mbit, an additional dram address bit is required. if bit 24 is set to 1, dadr[12] is driven on dmareq[3]* pin. if bit 24 is set to 0, it is driven on adp[0] pin. note: if ecc is implemented in the system, adp[0] cannot be used as dadr[12]. to use dadr[12], program bit 24 to 1 and use dmareq[3]* as dadr[12]. 5.1.3 registered sdram support the GT-96100A sdram controller can be configured to interface registered sdram dimms. setting bit 23 to 1means the registered sdram is enabled and the sdram controller drives and samples sdram signals accordingly. the sdram controller compensates the clock cycle needed for the dimm sam- ples sdram control signals. only 64-bit registered sdrams are supported. 5.1.4 sdram operation mode register (0x474) the sdram operation mode register is a 3-bit register used to execute commands other than standard memory reads and writes to the sdram. these operations include: ? normal sdram mode (0x0) ? nop commands (0x1) ? precharge all banks (0x2) ? writing to the sdram mode register (0x3) ? force a refresh cycle (0x4) in order to execute one of the above commands on the sdram, the following procedure must occur: 1. sdram operation mode register must be written the corresponding value. either the cpu or a pci device can master this transaction. 2. this write must be followed by a dummy word (32-bit) write to the corresponding sdram. 3. to complete the command, the sdram operation mode register must be written 0x0 to place it back into normal sdram mode. 5.1.4.1 normal sdram mode the sdram operation mode register must be written 0x0 to enable normal reading and writing to the sdram. 5.1.4.2 nop commands the nop command is used to perform a nop to an sdram which is selected by the sdram chip select (scs[3:0]*). this prevents unwanted commands from being registered during idle or wait states. 5.1.4.3 precharge all banks the precharge bank command is used to deactivate the open row in a particular bank or the open row in both banks. once a bank has been precharged, it is in the idle state and must be activated prior to any read or write commands being issued to that bank. GT-96100A advanced communication controller revision 1.0 103 5.1.4.4 writing to the sdram?s parameter register each sdram has its own mode register. the mode register defines the specific operation mode for the sdram. this definition includes the selection of a burst length, scas latency, operating mode, etc. note: refer to the sdram data sheet for more information about this register. typically, the mode register of each sdram is initialized on boot-up of the system and is kept static. the gt- 96100a has the flexibility to allow the cpu or a pci master to update the sdram?s mode register at any time during the operation. the parameters that the GT-96100A can change are the cas latency and the burst length. to change these parameters in the sdram?s mode register: 1. update the corresponding sdram bank parameters register (0x44c - 0x458) with the correct values. 2. the sdram operation mode register must be written to 0x3. this indicates a write command to the sdram mode register. 3. this write must be followed by a dummy word (32-bit) write to the corresponding sdram whose mode register must be updated. 4. finally, the sdram operation mode register must be written 0x0 to place it back into normal sdram mode. the GT-96100A uses the following procedure to automatically initialize the sdram on boot up. note: this default initialization can be easily overwritten by the procedure described above. 1. sras* and dwr* are asserted with dadr[10] high and scs[3:0] = 0000. this indicates a precharge to all sdram banks. 2. sras* and scas* are asserted with scs[3:0] = 0000. this indicates a cbr (cas before ras) refresh to all sdram banks. this occurs twice in a row. 3. sras*, scas*, and dwr* are asserted four times in a row. - once with scs[3:0] = 1110. - once with scs[3:0] = 1101. - once with scs[3:0] = 1011. - and, once with scs[3:0] = 0111. this command programs each of the sdram mode registers by activating each of the four chip selects (scs[3:0]) individually. the GT-96100A automatically initializes the sdram on boot up to sub-block burst ordering as required for mips cpus block reads. note: the GT-96100A always programs the sdram?s mode register to burst in sub-block order which sup- port the mips cpu burst order. the other modes that are programmed following boot up are the default values of the sdram control and parameters register. set the GT-96100A to initialize to linear ordering by programing sdram burst mode register to 0x9 and then following the above procedure. initializing to linear ordering is only possible with a linear burst read type cpu. 5.1.4.5 force refresh the force refresh command is used to execute a refresh cycle on the particular bank that is accessed. GT-96100A advanced communication controller 104 revision 1.0 5.1.5 sdram address decode register (0x47c) the address decode register is a three bit register which determines how bits of an address, presented on the sysad or pci bus, are translated to row and column address bits on dadr[12:0] and banksel[1:0]. this flexibil- ity allows the designer to choose the address decode setting. this gives the software the best chance this improves the software?s capability of interleaving and enhancing overall system performance. note: the row and column address translation is different for 16 mbit, 64/128 mbit, 256 mbit sdrams, 32- bit and 64-bit sdram banks. the address decoding depends on the setting of addrdecode. see table 76 for the sras* and scas* address translation from the sysad interface and pci. table 72: sysad/pci address decoding for 32-bit sdram, 16 mbit addrdecode, 0x47c sysad/pci bits used for sras* on banksel[0], dadr[10:0] sysad/pci bits used for scas* on banksel[0], dadr[10:0] 000 4, 21-11 4, ?0?, 23-22, 10-5, 3-2 001 5, 21-11 5, ?0?, 23-22, 10-6, 4-2 010 11, 21-12, 10 11, ?0?, 23-22, 9-2 011 12, 21-13, 11-10 12, ?0?, 23-22, 9-2 100 20, 21, 19-10 20, ?0?, 23-22, 9-2 101 21, 20-10 21, ?0?, 23-22, 9-2 110 22, 21-11 22, ?0?, 23, 10-2 (only for x4 & x8) 111 23, 21-11 23, ?0?, 22, 10-2 (only for x4) table 73: sysad/pci address decoding for 64-bit sdram, 256/512 mbit addrdecode, sysad/pci bits used for sras* on banksel[0], banksel[1], dadr[12:0] sysad/pci bits used for scas* on banksel[0], banksel[1], dadr[12:0] 000 illegal setting for 64, 128mbit and 256mbit sdram 001 6, 7, 25-13 6, 7, 29-28, ?0?, 27-26, 12-8, 5-3 010 11, 12, 25-13 11, 12, 29-28, ?0?, 27-26, 10-3 011 13, 14, 25-15, 12-11 13, 14, 29-28, ?0?, 27-26, 10-3 100 21, 22, 25-23, 20-11 21, 22, 29-28, ?0?, 27-26, 10-3 101 23, 24, 25, 22-11 23, 24, 29-28, ?0?, 27-26, 10-3 110 24, 25, 23-11 24, 25, 29-28, ?0?, 27-26, 10-3 111 25, 26, 27, 22-11 25, 26, 29-28, ?0?, 24-23, 10-3 GT-96100A advanced communication controller revision 1.0 105 table 74: sysad/pci address decoding for 32-bit sdram, 64 mbit addrdecode, 0x47c sysad/pci bits used for sras* on banksel[0], banksel[1], dadr[11:0] sysad/pci bits used for scas* on banksel[0], banksel[1], dadr[11:0] 000 illegal setting for 64, 128mbit and 256mbit sdram 001 5, 6, 23-12 5, 6, ?00?, 25-24, 11-7, 4-2 010 11, 12, 23-13, 10 11, 12, ?00?, 25-24, 9-2 011 12, 13, 23-14, 11-10 12, 13, ?00?, 25-24, 9-2 100 20, 21, 23-22, 19-10 20, 21, ?00?, 25-24, 9-2 101 22, 23, 21-10 22, 23, ?00?, 25-24, 9-2 110 23, 24, 21-10 23, 24, ?00?, 25, 22, 9-2 (only for x4 & x8) 111 24, 25, 21-10 24, 25, ?00?, 26, 22, 9-2 (only for x4) table 75: sysad/pci address decoding for 64-bit sdram, 64/128 mbit addrdecode, 0x47c sysad/pci bits used for sras* on banksel[0], banksel[1], dadr[11:0] sysad/pci bits used for scas* on banksel[0], banksel[1], dadr[11:0] 000 illegal setting for 64, 128mbit and 256mbit sdram 001 6, 7, 24-13 6, 7, 27, ?0?, 26-25, 12-8, 5-3 010 11, 12, 24-13 11, 12, 27, ?0?, 26-25, 10-3 011 13, 14, 24-15, 12-11 13, 14, 27, ?0?, 26-25, 10-3 100 21, 22, 24-23, 20-11 21, 22, 27, ?0?, 26-25, 10-3 101 23, 24, 22-11 23, 24, 27, ?0?, 26-25, 10-3 110 24, 25, 22-11 24, 25, 27, ?0?, 26, 23, 10-3 (only for x4 & x8) 111 25, 26, 22-11 25, 26, 27, ?0?, 24-23, 10-3 (only for x4) GT-96100A advanced communication controller 106 revision 1.0 5.2 connecting the address bus to the sdram connecting the address bus to sdram is very simple with the GT-96100A. the sdram controller has its own address bus and its depends on whether a 16 mbit or 64 mbit sdrams are being used. 5.2.1 16 mbit sdrams for 16 mbit sdrams, dadr[10:0] and banksel[0] are outputs of the GT-96100A and must be directly con- nected to address bits 10-0 and bank select of the actual sdram. note: dadr[11] and banksel[1] are not used when connecting to 16 mbit sdrams. these lines are in high- z state when accessing 16mbit sdrams. during a sras cycle, a valid row address is placed on the dadr[10:0] and banksel[0] lines. during the scas cycle, a valid column address is placed on dadr[9:0] (10-bit). dadr[10] is used as the auto-precharge select bit and is always written 0 during scas cycles. banksel[0] is held constant from the sras cycle. with 16 mbit sdrams, the GT-96100A supports a maximum of 4m addresses, 12 address bits for sras and 10 address bits for scas. 5.2.2 64/128 mbit sdrams for 64/128 mbit sdrams, dadr[11:0] and banksel[1:0] are outputs of the GT-96100A and must be directly connected to address bits 11-0 and bank select of the actual sdram. during a sras cycle, a valid row address is placed on the dadr[11:0] and banksel lines. during the scas cycle, a valid column address is placed on dadr[11,9:0] (11-bit). dadr[10] is used as the auto-precharge select bit and is always written 0 during scas cycles. banksel is held constant from the sras cycle. with 64 mbit sdrams, the GT-96100A supports a maximum of 16m addresses, 14 address bits for sras and 10 address bits for scas (dadr[11] is ignored and is in high-z state when accessing 64 mbit sdrams). table 76: sysad/pci address decoding for 64-bit sdram, 256 mbit addrdecode, 0x47c sysad/pci bits used for sras* on banksel[0], banksel[1], dadr[12:0] sysad/pci bits used for scas* on banksel[0], banksel[1], dadr[12:0] 000 illegal setting for 64, 128mbit and 256mbit sdram 001 6, 7, 25-13 6, 7, 29-28, ?0?, 27-26, 12-8, 5-3 010 11, 12, 25-13 11, 12, 29-28, ?0?, 27-26, 10-3 011 13, 14, 25-15, 12-11 13, 14, 29-28, ?0?, 27-26, 10-3 100 21, 22, 25-23, 20-11 21, 22, 29-28, ?0?, 27-26, 10-3 101 23, 24, 25, 22-11 23, 24, 29-28, ?0?, 27-26, 10-3 110 24, 25, 23-11 24, 25, 29-28, ?0?, 27-26, 10-3 111 25, 26, 27, 22-11 25, 26, 29-28, ?0?, 24-23, 10-3 GT-96100A advanced communication controller revision 1.0 107 with 128 mbit sdrams, the GT-96100A supports a maximum of 32m addresses, 14 address bits for sras and 11 address bits for scas. 5.2.3 256 mbit sdrams for 256/512 mbit sdrams, dadr[12:0] and banksel[1:0] are outputs of the GT-96100A and must be con- nected directly to address bits 12-0 and bank select of the actual sdram. during a sras cycle, a valid row address is placed on the dadr[12:0] and banksel lines. during the scas cycle, a valid column address is placed on dadr[12-11,9:0] (12-bit). dadr[10] is used as the auto-precharge select bit and is always written 0 during scas cycles. banksel is held constant from the sras cycle. with 256/512 mbit sdrams, the GT-96100A supports a maximum of 128m addresses, 15 address bits in sras and 12 address bits in scas. for a 64 bit wide sdram built from 128mx4bit memories, 1gbyte can be addressed by a single sdram device decoder. GT-96100A advanced communication controller 108 revision 1.0 figure 16: 512 mbit/64-bit sdram connection to memory bus using x8 devices 5.3 programmable sdram parameters the sdram controller of the GT-96100A device supports a wide range of sdrams with different access times and each bank can be programmed independently by the sdram bank[3:0] parameter registers (0x44c-0x458). these parameters include the number of clock cycles (based on tclk) between active sras* and scas*. note: to update the scas* latency or the burst length, follow the procedure outlined in section 5.1.4.4 ?writing to the sdram?s parameter register? on page 103 to update the sdram?s mode register. 64mx8 ram #1 64mx8 ram #2 64mx8 ram #3 64mx8 ram #4 64mx8 ram #5 64mx8 ram #6 64mx8 ram #7 64mx8 ram #8 64mx8 ram #9 512mbit sdram 64mx8 ram #1 64mx8 ram #2 64mx8 ram #3 64mx8 ram #4 64mx8 ram #5 64mx8 ram #6 64mx8 ram #7 64mx8 ram #8 64mx8 ram #9 512mbit sdram sras* scas* dwr scs[1] bank 0, cs0* GT-96100A dadr[12:0] banksel[1:0] sdqm[0] sdqm[1] sdqm[2] sdqm[3] sdqm[4] sdqm[5] sdqm[6] sdqm[7] d[63:0],adp[7:0] d[63:0],adp[7:0] scs[0] d[7:0] d[15:8] d[23:16] d[31:24] d[39:32] d[47:40] d[55:48] d[63:56] adp[7:0] d[7:0] d[15:8] d[23:16] d[31:24] d[39:32] d[47:40] d[55:48] d[63:56] adp[7:0] bank 1, cs1* tclk sdqm[0] sdqm[1] sdqm[2] sdqm[3] sdqm[4] sdqm[5] sdqm[6] sdqm[7] parity byte enabled, always asserted (gnd) GT-96100A advanced communication controller revision 1.0 109 table 77 describes the programmable functions of the sdram parameters. table 77: programmable sdram parameters function description scas* latency scas* latency is the number of tclks from the assertion of scas* to the sampling of the first read data. this parameter can be programmed to be either 2 or 3 tclks. selecting this parameter depends on tclk frequency and the speed grade of the sdram. note: check your sdram data sheet for the most optimal setting. flow-through bit 2 specifies the number of times that the data is sampled by the GT-96100A on sdram reads when bypass is not enabled (bit 9 = 0). this option is included for future designs which will run at faster clock frequencies. note: as of january 1999, flow-through mode must always be enabled (bit 2 = 1). if ecc or registered sdram are used, flow-through must be disabled (bit 2 = 0). sras* precharge bit 3 specifies the sras precharge time. this parameter specifies the number of tclks following a precharge cycle that a new sras* transaction may generate. 64-bit interleaving bit 5 specifies the number of banks that are supported for interleaving if the bank is set for 64/128/256 mbit sdram. if the bank is not set for 64/128/256 mbit sdram (bit 11 = 0), the setting of this bit is irrelevant. bank width bit 6 specifies the data width of the particular bank. bank location bit 7 specifies the location of the bank if the bank is set for 32-bit sdram. if the bank is not set for 32-bit sdram (bit 6 = 1), the setting of this bit is irrelevant. ecc support bit 8 enables or disables ecc on a 64-bit wide sdram bank. 64-bit bypass mode for cpu reads bit 9 enables or disables 64-bit sdram read bypass. note: this option is only for sdram banks configured as 64-bit (the option is not available for devices). an optional bypass mode is available for cpu reads where a clock cycle of latency can be eliminated when the cpu executes read cycles from 64-bit sdram. the bypass mode requires additional bus switches to enable direct data flow to the cpu. instead of passing response data from the sdram to the GT-96100A prior to presenting it to the cpu, data flows directly from the sdram to the cpu via bus switches. this reduces the latency from validout* to validin* from 9 tclk cycles to 8. note: the bypass is used for partial reads as well. reads from 64-bit sdram are no longer sampled by the GT-96100A prior to presenting the data to the cpu. 64-bit bypass can only be enabled if the bank is set for 64-bit (bit 6 = 1). no writes are transferred via the bypass switches at any time. sras* to scas* bit 10 specifies the number of tclks that the GT-96100A inserts between the asser- tion of sras* with a valid row address to the assertion of scas* with a valid col- umn address. GT-96100A advanced communication controller 110 revision 1.0 5.4 sdram performance depending on the setting of certain variables, sdram performance can vary on both the cpu and pci interface. 5.4.1 cpu access to sdram sdram performance on the cpu interface is based on the latency between the cpu?s assertion of validout* to the GT-96100A?s assertion of validin* returning the first data on a burst read (cache line read). performance is different if the 64-bit bypass feature is enabled. table 78 summarizes the latency between valid- out* and validin* on sdram reads. after the first data is read, the remaining data is returned with zero wait states. for example, if bypass is enabled and the cpu executes a cache line read from memory, data will be returned with 8-1-1-1 performance when bypass is enabled. on cpu writes to sdram, the data cycles will follow the address cycle with zero wait states. further, the next data of a burst can also be written on the next clock cycle (zero wait states). 5.4.2 pci read performance from sdram the following sections outlines sdram memory performance. these figures depend on a number of variables including the pclk/tclk ratio, as well as the sync. mode that the device is configured for. the following numbers are based on the fastest sdram settings. 16/64/128/256 mbit sdram configuration bits [14,11] specify when the particular bank supports 16, 64/128, or 256 mbit sdrams. note: the value of 10 is a reserved setting and must not be used. burst length bit 13 specifies the data burst length supported for the particular sdram bank. the data can be either 32 or 64 bit, depending on the setting of bit 6. table 78: cpu sdram performance on reads sdram device number of tclks between validout* to validin* bypass enabled 1 1. see table 77 for more information about the bypass feature. 8 bypass not enabled 9 table 77: programmable sdram parameters (continued) function description GT-96100A advanced communication controller revision 1.0 111 performance is rated on three events: there are five different sync. modes that the GT-96100A can be placed in depending on the pclk/tclk ratio. these sync. modes are: table 79: events determining pci read performance from sdram event description pci read request from sdram. this event is based on the number of clocks between frame* being asserted by a pci master to the assertion of sras* by the sdram controller. data from sdram con- troller to pci. this event is based on the number of clocks between the first data placed on the ad bus until trdy* is asserted on the pci bus by the GT-96100A. latency till first data. this event is based on the number of clocks between a pci master asserting frame* to the assertion of trdy* by the GT-96100A. table 80: GT-96100A sync. modes sync. mode description sync mode 0, x00 no assumptions on tclk/pclk ratio. sync mode 1, 001 pclk frequency is greater than or equal to 1/2 tclk frequency. sync mode 2, 01x pclk frequency is synchronized 1 to tclk frequency and greater than or equal to 1/2 tclk frequency 1. if tclk and pclk are synchronized, see section 32.1 ?tclk/pclk restrictions? on page 516 . sync mode 5, 101 pclk frequency is greater than or equal to 1/3 tclk frequency but smaller than 1/2 tclk frequency. sync mode 6, 11x pclk frequency is synchronized to tclk frequency and greater than or equal to 1/3 tclk frequency but smaller than 1/2 tclk frequency. GT-96100A advanced communication controller 112 revision 1.0 table 81: sdram performance summary pci read accesses tclk/pclk frequency (mhz) sync. mode event # of tclk # of pclk 100/33 0 a b c 9 12 26 3 5 10 5a b c 10 12 26 3 5 10 100/50 0 a b c 8 8 20 4 5 12 1a b c 8 8 20 4 5 12 100/66 0 a b c 5 6 16 4 5 12 1a b c 6 6 16 4 5 12 100/33 0 a b c 14 12 30 5 4 10 5a b c 14 12 30 5 4 10 6 or 7 a b c 12 8 24 4 3 8 100/50 0 a b c 11 9 24 6 5 12 1a b c 11 9 24 6 5 12 2a b c 9 5 18 5 3 9 GT-96100A advanced communication controller revision 1.0 113 5.5 sdram bank interleaving the GT-96100A supports two bank interleaving with 16 mbit sdram and two or four bank interleaving with 64 mbit sdrams. the sdram address control register (0x47c) determines what address bits are used for sras and scas cycles. this allows flexibility for different software applications to select an address decoding scheme which may give data accesses a better probability of interleaving. interleaving provides higher system performance by hiding sras to scas cycles and precharge time of a pend- ing transaction during the data cycles of a current transaction. this reduces the number of wait states before data can be read from or written to sdram, thus, increasing bandwidth. interleaving occurs when two independent resources require access to sdram. these resources can be the cpu, pci_0, pci_1, or one of the idma con- trollers. at the end of every sdram memory transaction, the GT-96100A will precharge the bank. 5.6 unified memory architecture (uma) support the GT-96100A supports uma. this feature allows an external master device to share the same physical sdram memory is controlled by the GT-96100A device. this feature works according to the vesa unified memory architecture (vuma) specification 1 . a vuma device refers to any type of controller which needs to share the same physical system memory and have direct access to it as shown in figure 17 . 100/66 0 a b c 9 8 21 6 6 14 1a b c 9 8 21 6 6 14 1. more information about the vesa unified memory architecture can be found at http://www.vesa.org table 81: sdram performance summary pci read accesses (continued) tclk/pclk frequency (mhz) sync. mode event # of tclk # of pclk GT-96100A advanced communication controller 114 revision 1.0 figure 17: vuma device and the GT-96100A sharing sdram 5.6.1 uma hardware support uma is enabled by a pin strapping option. if dadr[7] is sampled low on reset, dmareq[0]* is pro- grammed to function as mreq*. the bypsoe* pin will function as mgnt* as long as bit 9 is 0 for all of the sdram bank parameters registers (bypass disabled). note: the bypass feature and uma cannot be used simultaneously. mreq* is an input into the GT-96100A and must be an output for the vuma device. this signal is used by the vuma device to make a request of GT-96100A to access the shared sdram. mreq* should be driven by the vuma device on a rising edge of tclk. mreq* is sampled on a rising edge of tclk by the GT-96100A. mgnt* is an output of the GT-96100A and must be an input to the vuma device. this signal is used by the gt- 96100a to inform the vuma device that it can access the shared sdram. mgnt* is driven by the GT-96100A on a rising edge of tclk. mgnt* must be sampled by the vuma device on a rising edge of tclk. note: the ac timing parameters are shown in section 32. ?ac timing? on page 513 . table 82: uma ac timing parameters signals description min. max. unit loading mreq* setup. 3 ns mreq* hold. 1 ns mgnt* output delay from tclk rising. 210ns30 pf gt?96100a cpu pci vuma device sdram mreq* mgnt* tclk treq* GT-96100A advanced communication controller revision 1.0 115 5.6.2 sdram pins once mgnt* is asserted by the GT-96100A and the vuma device is granted access to sdram, the scs[3:0]*, sras*, scas*, dwr*, ad[63:0], dqm[8:0], dadr[11:0], and banksel[1:0] are held in sustained tri-state until the GT-96100A regains access to sdram. during this period, the vuma device must drive these signals to access sdram. when the GT-96100A and the vuma device hands the bus over to each other, they must drive all of the above signals high for one tclk and then float the pins (except the sdram address lines). the sdram address lines do not need to be driven high before floating the bus. a sample waveform is shown in figure 18 . figure 18: handing the bus over 5.6.3 address decoding the GT-96100A complies with the standard for cpu address to sdram row and column addressing. see sec- tion 5.1.5 ?sdram address decode register (0x47c)? on page 104 to see how the cpu address translation is performed. this register (0x47c) should be programmed with the binary value of 010 in order to properly use the uma feature when using 16 mbit/64-bit sdram. note: as of january 1999, there is no standard for uma sdram addressing when using 16 mbit/32-bit sdram or 64 mbit sdrams (32 or 64 bit). 5.6.4 arbitration as shown in figure 17 on page 114 , the vuma device arbitrates with the GT-96100A for access to sdram through mreq* and mgnt*, which should be synchronous to tclk. the GT-96100A is always the default owner of the sdram and access to this memory is only allowed to the vuma device upon demand. the GT-96100A has the right to take the vuma device off of the bus by de-asserting mgnt*. the vuma device may request access to sdram with either a low or high priority, and both of these priorities are conveyed to the core logic through the mreq* signal. tclk mreq* mgnt* scs[3:0]*, sras*, scas*, dwr*, ad[63:0], dqm[8:0] banksel[1:0],dadr[11:0] GT-96100A driving GT-96100A driving vuma driving vuma GT-96100A advanced communication controller 116 revision 1.0 figure 19: mreq* requests from the vuma device 5.6.4.1 vuma device access to sdram rules there are certain rules that must be followed when the vuma device makes a request for access to the sdram. 1. once mreq* is asserted by the vuma device for a low priority request, it must keep it asserted until the vuma device is given access to sdram via mgnt*. the only reason to change the status of the mreq* pin is to raise a high priority request or raise the priority of an already pending low priority request. - if mgnt* is sampled asserted, the vuma device must not de-assert mreq*. instead, the vuma device will have ownership of sdram and must continue asserting mreq* until it has completed its transaction. - if mgnt* is sampled de-asserted, the vuma device can de-assert mreq* for one clock and assert it again regardless of the status of mgnt*. after re-assertion, the vuma device must keep mreq* asserted until the GT-96100A gives the vuma device access to sdram via mgnt*. 2. the vuma device may only assert the mreq* for the purpose of accessing sdram and must stay asserted until mgnt* is sampled asserted except to raise the priority request. no speculative requests or request abortion is allowed. 3. once the vuma device samples mgnt* as asserted, it gains and retains access to sdram until mreq* is de-asserted. 4. the GT-96100A always asserts mgnt* for one clock cycle only, and immediately requests back own- ership of the bus. note : any other transitions asserted other than those shown in this figure will keep the state machine in the current state. tclk mreq* low priority request tclk mreq* high priority request tclk mreq* pending low priority converted to a high priority GT-96100A advanced communication controller revision 1.0 117 5. the vuma device retains ownership of sdram indefinitely. the standard calls for the vuma device to keep ownership for no longer than 60 tclks before it must release the bus. this is not a requirement for the GT-96100A and it will wait until the vuma device releases the bus by de-asserting mreq*. 6. when the vuma device has ownership of the bus, it has full responsibility to execute refresh cycles on the sdram. 7. once the vuma device de-asserts mreq* to transfer ownership back to the GT-96100A either on its own, or because of a preemption requires, mreq* should be de-asserted for at least 2 tclks before asserting it again to raise a request. 5.6.5 latencies, low and high priority if a vuma device places a low priority request for access to sdram, there is no set time specified by the gt- 96100a to assert mgnt*. once there are no pending transactions to the memory controller, mgnt* is asserted. if a vuma device places a high priority request for an access to sdram, the GT-96100A has a maximum of 35 tclks before it asserts mgnt*. 5.6.6 total request the GT-96100A immediately requests back ownership of the bus after mgnt* assertion. if bit 4 of sdram bank2 parameters register is set to 1, dmareq[3]*/scas* pin functions as a total request pin. it indicates that there is a real internal request inside the GT-96100A that requires sdram bus ownership. note: this may cause some difficulty to implement a fair arbitration mechanism on the sdram bus. 5.6.7 disable refresh in some applications, the GT-96100A will be most of the time off the sdram bus. the bus master has full responsibility to execute refresh cycles on the sdram. in such applications, the user may want to disable the GT-96100A?s refresh cycles (make memory controller arbi- tration cycle shorter). disable refresh cycles by setting bit 4 of sdram bank1 parameters register to 1. 5.6.8 internal register reads with uma enabled in order for the GT-96100A to return the data of an internal register read, the sdram and memory controller must have control over the ad bus. therefore, the logic controller the input of mreq* to the GT-96100A must de-assert its request of the memory. the internal register read transaction is held off until the GT-96100A obtains mastership of the memory bus. GT-96100A advanced communication controller 118 revision 1.0 5.7 device controller the device controller supports up to five group of devices. various access parameters can be programmed on a per group basis as each group has its own parameters register (0x45c - 0x46c). the supported memory space of each device can vary for each bank up to 256 mbytes. the width of each device may be 8, 16, 32 or 64-bits. the maximum total device address space is 512 mbytes for all five groups. the five individual chip selects are typically broken up into four individual device groups plus one chip select for a boot device (non-volatile memory). each device group can have unique programmable timing parameters to accommodate different device types (e.g. flash, rom, i/o controllers). the devices share the local ad bus with the sdram. unlike the sdram, the devices use the ad bus as a multiplexed address and data bus. in the address phase, the device controller puts an address on the ad bus with a corresponding chip select asserted. ale indicates the ad bus is output as address with a valid cs*. ale is used to latch the address and the cs* in an external latch. ale is high by default, making the latch transparent. 1 ale goes low a half clock cycle before cstiming* is asserted for the particular read or write transaction. at the completion of the transaction, ale goes high again on the same rising tclk that cstiming* is de-asserted. cs* must then be qualified (or-tied) with cstiming*. a read or write cycle is indicated by devrw*. the cstiming* signal is valid for the programmable number of cycles of the specific cs* is active. turnoff, accto- first and acctonext can be set in registers 0x45c - 0x46c for each group?s read timing parameters. aletowr, wractive, and wrhigh are set for each group?s write timing parameters. there are certain restrictions to setting these timing parameters. see section 5.9 ?memory controller restrictions? on page 126 before configuring these bits. note: some of these parameters can be extended by the ready* pin. see section 5.7.10 ?ready* support? on page 122 . 5.7.1 turnoff turnoff is the number of tclk cycles that the GT-96100A does not drive the memory bus after a read from a device. this prevents contention on the memory bus after a read cycle for a slow device. this parameter is measured from the number of cycles between the de-assertion of devoe* (an externally extracted signal which is the logical or between cstiming* and inverted devrw*) to an new ad bus cycle. 5.7.2 acctofirst acctofirst defines the number of cycles in a read access from the assertion of cs* (first rising tclk where cs* is asserted low) to the cycle that the first data is sampled by the GT-96100A. note: this parameter can be extended by the ready* pin. see section 5.7.10 ?ready* support? on page 122 . 1. note that this definition of ale is slightly different than the gt-64010a/11/14/60. ale on these devices is default low, and is only asserted high for a half clock cycle to latch the address. this change in definition for ale on the GT-96100A has no affect on system performance or architecture. GT-96100A advanced communication controller revision 1.0 119 5.7.3 acctonext acctonext defines the number of cycles in a read access from the cycle that the first data is latched to the cycle to the next data is latched (in burst accesses). this parameter can also be thought of as the delay between the ris- ing edge of tclk which data is latched to the rising edge of tclk where the next data is latched in a burst cycle. note: this parameter can be extended by the ready* pin. see section 5.7.10 ?ready* support? on page 122 . 5.7.4 aletowr there are eight byte write signals, wr[7:0]*. aletowr can also be thought of as the delay between the rising edge of tclk which drives ale low to the assertion of wr*, or for the first write pulse. note: the wr[7:0]* signals are asserted and de-asserted off of the falling edge of tclk. 5.7.5 wractive wractive is the number of tclks that wr* are active (asserted). this parameter is measured from the first rising edge of tclk where wr* is asserted low to the last rising edge of tclk where wr* is low for that particular write pulse. note: this parameter can be extended by the ready* pin. see section 5.7.10 ?ready* support? on page 122 . the wr[7:0]* signals are asserted and de-asserted off of the falling edge of tclk. 5.7.6 wrhigh wrhigh is the number of tclks that wr* is inactive between burst writes. this parameter is measured from the first rising edge of tclk where wr* is de-asserted high to the last rising edge of tclk where wr* is high. on the next rising edge of tclk, wr* is asserted low for the next write pulse. note: the wr[7:0]* signals are asserted and de-asserted off of the falling edge of tclk. the previous data remains on the ad bus during wrhigh. 5.7.7 device bank width and location bit 21:20 of the device bank[3:0] parameter registers (0x45c-0x46c), devwidth, specifies whether the data width of the particular device bank is 8, 16, 32 (default except for bootcs*), or 64 bits. if the bank is set for 8-, 16-, or 32-bit operation, it can either reside on the even half (31:0) or odd half (63:32) by setting bit 23, devloc. selecting the even or the odd half allows for load balancing. in case of a 64-bit device, devloc has no meaning. GT-96100A advanced communication controller 120 revision 1.0 figure 20: waveform showing device read parameters notes : 1. cs* is driven off the same rising tclk* as ale. throughout consecutive transactions to the same device, cs* remains asserted. this is why cs* must always be qualified with cstiming. 2. the gt?96100a may start a new ad cycle after turnoff. address tclk ale ad[63:0] acctofirst = 3 turnoff = 2 2 cs* 1 cstiming* devrw* data1 data2 acctonext = 1 GT-96100A advanced communication controller revision 1.0 121 figure 21: waveform showing device write parameters 5.7.8 burst writes the device controller supports up to eight word burst accesses. the burst address is supported by a 3-bit wide address bus (badr[2:0]) that is different from the latched address on the multiplexed ad bus. note: badr[2:0] are the same pins as the least significant sdram address lines, dadr[2:0]. see section 33. ?pinout table, 492 pin bga? on page 533 for more information. 5.7.9 packing and unpacking data and burst support the ad bus supports the packing of data into a 64-bit double word, in reads from devices that are 8-, 16-, or 32- bits wide. devices that are 8- or 16-bits wide are supported by partial reads (up to 64-bits). the controller supports cpu writes of one to eight bytes to 8-bit or 16-bit wide devices. therefore, 8 and 16-bit devices must not be mapped to cacheable regions. the reason is that the r4xxx/r5000/r7000 have an eight or 16 word (32 or 64 bytes) cache line size. this would equate to a burst of 32/64 8-bit accesses or 16/32 16-bit accesses. the GT-96100A supports cached accesses to 32- and 64-bit device spaces. it supports dma/pci writes of one to eight bytes to 8-bit or 16-bit wide devices. address tclk ale ad[63:0] aletowr = 2 wractive =1 wr[7:0]* 2 cs* 1 cstiming* devrw* notes : 1. cs* is driven off the same rising tclk* as ale. throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 2. wr[7:0]* are asserted and deasserted from the falling edge of tclk. data 1 data 2 data 3 data 4 wrhigh =1 GT-96100A advanced communication controller 122 revision 1.0 5.7.10 ready* support the ready* pin is sampled on three occasions: ? one clock before the data is sampled to the GT-96100A. ? during both acctofirst (see figure 22 ) and acctonext (see figure 23 ) phases of read cycles. ? on the last rising edge of the wractive (see below) phase during a write cycle. during all other phases ready* is not sampled by the GT-96100A. if ready* is not asserted during the wractive, acctofirst, or acctonext phases. these phases are extended until ready* is asserted again. the transaction may be indefinitely held off until ready* is asserted. note: there are no sdram refreshes as long as an access to a device is not completed. use ready* carefully on device accesses so it not interfere with the sdram refresh. figure 22: ready* extending acctofirst on read cycle tclk ale acctofirst set to 5 cs* 1 cstiming* devrw* notes: 1. cs* is driven off the same rising tclk* as ale. throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 2. ready* is sampled as deasserted one clock before data should be sampled according to acctofirst. ad[63:0] is not sampled by the gt-64120 on the following rising tclk. 3. ready* is asserted on some following rising tclk. 4. ad[63:0] (data 1) is sampled on the following rising tclk of the rising tclk that ready* was asserted. effectively, acctofirst is 7 in this example (instead of the programmed 5). 4 ready* 2 3 address ad[63:0] data 1 driven from device 1. cs* is driven off the same rising tclk* as ale. throughout consecutive transactions to the same device, cs* will remain asse rted. this is why cs* must always be qualified with cstiming*. 2. ready* is sampled as deasserted one clock before data should be sampled according to acctofirst. ad[63:0] is not sampled by g t?96100a on the following rising tclk. 3. ready* is asserted on some following rising tclk. 4. ad[63:0] (data1) is sampled on the following rising tclk of the rising tclk that ready* was asserted. effectively, acctofirst is 7 in this example (instead of programmed 5). GT-96100A advanced communication controller revision 1.0 123 figure 23: ready* extending acctonext on read cycle address tclk ale ad[63:0] acctofirst = 5 acctonext programmed to 3 data 1 driven from device cs* 2 cstiming* devrw* notes: 1. cs* is driven off the same rising tclk* as ale. throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 2. ready* is sampled as asserted one clock before data should be sampled according to acctofirst. data 1 is sampled on ad[63:0]. 3. ready* is sampled as de-asserted one clock before data should be sampled according to acctonext. data 2 is not sampled. 4. ready* is asserted on some following rising tclk. 5. ad[63:0] (data 2) is sampled on the following rising tclk of the rising tclk that ready* was asserted. effectively, acctonext is 5 (instead of the programmed 3). data 2 driven from device 4 ready* 2 3 5 GT-96100A advanced communication controller 124 revision 1.0 figure 24: extending wractive parameter on write cycle 5.7.11 parity support for devices the GT-96100A has no dedicated logic to support device parity. if device parity checking is required, it can be implemented externally using ?511 devices and some logic for interrupt generation. still, the GT-96100A generates even parity on cpu sysadc lines during cpu read transaction from devices. address tclk ale ad[63:0] aletowr = 3 wractive = 3 wrhigh= 3 wractive programmed to 3 wr* 2 gt?96100 drives valid data 1 gt?96100 drives valid data 2 cs* 1 cstiming* devrw* notes: 1. cs* is driven off the same rising tclk* as ale. throughout consecutive transactions to the same device, cs* will remain ass erted. this is why cs* must always be qualified with cstiming*. 2. wr[7:0]* are asserted and de-asserted from the falling edge of tclk. 3. ready* is asserted on last rising tclk of wractive, therefore, the gt?96100a assumes the device is written to correctly and continues to the next write cycle. 4. ready* is deasserted on the last rising tclk of wractive, therefore, the gt?96100a does not continue to the next write cycl e effectly extending the wractive parameter. wr* remains asserted. 5. ready* is asserted on the next rising tclk, therefore, the gt?96100a assumes the device has been written to correctly and c ontinues to the next cycle (end of write transaction). effectively, wractive is 4 (instead of the programmed 3). for clarification, if th ere was another word to burst, wrhigh would start counting from the rising tclk denoted by 5, not 4. ready* 3 4 5 GT-96100A advanced communication controller revision 1.0 125 5.8 programming the adp lines for other functions if ecc is enabled for any sdram bank, the adp lines function as pins used for reading and writing the ecc byte. if ecc is not implemented in the system, the adp lines are usable for other functions. these functions include duplicating the sdram control lines (used for load balancing) and duplicating the ale signal (used for load balancing). during reset, certain pins are sampled (either high or low) to select these pin functions, see section 22. ?reset configuration? on page 452 . if ecc is not enabled, and the adp lines are not programmed to function as other pins on reset, adp[3:0] will function as eot[3:0], see table 236, ?dma channel control register (0x840 - 0x84c),? on page 221 . fur- ther, adp[4] will be used as banksel[1] and adp[5] will be used as dadr[11]. adp[7:6] are unused. table 83 summarizes the functionality of the adp lines depending on system configuration. table 83: adp[7:0] pin functionality ecc in system no ecc in system primary pin (ecc enabled for any sdram bank) ecc not enabled for any sdram bank dmareq[1]* sampled high on reset dmareq[3]* sampled high on reset adp[0] eot[0] adp[1] eot[1] ale adp[2] eot[2] adp[3] eot[3] dwr* adp[4] banksel[1] adp[5] dadr[11] adp[6] scas* adp[7] sras* GT-96100A advanced communication controller 126 revision 1.0 5.9 memory controller restrictions 1. unless the boot device is 64-bits wide, the boot must be on the even half (bits 31:0 of ad[63:0] bus). 2. when working with an 8- or 16-bit configured bank, a read/write operation can not exceed 64-bits (eight bytes). since pci reads are always prefetchable, pci access to a 8- or 16-bit wide device is not allowed (unless frame* is asserted for a single pclk cycle). 3. when an erroneous address is issued or a burst operation is performed to an 8- or 16-bit device, the gt- 96100a forces an interrupt (unless masked). if a sequence of address misses occurs, there is no other interrupt prior to resetting the appropriate bit in the cause register and no new address is registered in the address decode error register (0x470) prior to reading it. 4. when the cpu reads from an address which is decoded in the cpu interface unit as being a hit for cs[2:0]* or bootcs* and cs[3]* and decoded as a miss in the sdram/device interface unit, the cycle completes only if ready* is asserted (i.e., driven low). although being a result of improper and inconsistent programming of the address space defining regis- ters, the following 2 workaround exist: - ready* must be asserted (low) when cstiming* is inactive (high). - if the ready* signal is not needed in the system, the ready* pin must be driven active (low). 5. the minimum parameter for turnoff, acctofirst, acctonext, wractive, and wrhigh is 1 and for aletowr is 3. 6. if address decode (register 0x47c) is set to 0, bursts of 64 bytes to 64-bit sdram are not supported. address decode mode 0 (0x47c) should not be used when using 64, 128, or 256mbit sdrams. 7. pci reads from 8- or 16-bit bank must not be prefetchable. 8. access to sdram during sdram initialization time after reset results in unpredictable behavior. 9. when sdram cas latency is 3, ras precharge time (bit 3 of sdram parameter register) must be programmed to 1. 10. when using 64/256 mbit sdram, address decode 0 is not allowed. 11. in order for memory controller to return data of an internal register read, it must have control over the ad bus. 12. when using aggressive prefetch, the highest address that can be read from the pci is the last dram address minus 0x8. 13. table 84 describes the limitation of a 32 bit device in the GT-96100A. GT-96100A advanced communication controller revision 1.0 127 table 84: 32-bit device limitations terminology word: 32 bit aligned: aligned to a word limitation during a read/write cycle of an odd number of words to a 32-bit device from an aligned address, or a read/write cycle to a 32-bit device to an unaligned address, an extra read/write occurs to the complementary word of the double- word address accessed with byte enables not active. this may result in destructive reads and loss of performance while accessing the device. examples 1. cpu writes one word to offset 0 of a 32-bit device. result: a write to offset 0 with wr* asserted and a write to offset 4 with wr* not asserted. 2. cpu writes one word to offset 4 of a 32 bit device. result: a write to offset 0 with wr* not asserted and a write to offset 4 with wr* asserted. 3. dma writes five words to offset 0 of a 32 bit device. result: burst of six bits to the device, with the last wr* not asserted. note: if ready* is used, the GT-96100A must sample it active an even num- ber of times. i.e., once for address 0 and once for address 4 (see example 1 above). workaround 1. if the device is always accessed for single word transfers, connect the ad[4:2], latched, to the device's least significant address pins instead of the badr[2:0]. this prevents destructive reads. 2. access the device always with an even number of words at double word aligned addresses (e.g. 0x0, 0x8, 0x10...). this means that the dma must have the dattranslimit field set to at least eight bytes. this will make sure there are no destructive reads and no loss of performance. GT-96100A advanced communication controller 128 revision 1.0 5.10 registered sdram interface restrictions 1. all sdram dimms must be registered (no support for registered and non-registered dimms in one system). 2. all sdram dimms are 64-bit (no support for 32-bit registered dimms). 3. bit 2 (flow-through) in all sdram parameters registers is set to 0. 5.11 memory interface control registers table 85: memory interface register map description offset page number sdram and device address decode scs[0]* low decode address 0x400 page 130 scs[0]* high decode address 0x404 page 130 scs[1]* low decode address 0x408 page 130 scs[1]* high decode address 0x40c page 130 scs[2]* low decode address 0x410 page 131 scs[2]* high decode address 0x414 page 131 scs[3]* low decode address 0x418 page 131 scs[3]* high decode address 0x41c page 131 cs[0]* low decode address 0x420 page 131 cs[0]* high decode address 0x424 page 132 cs[1]* low decode address 0x428 page 132 cs[1]* high decode address 0x42c page 132 cs[2]* low decode address 0x430 page 132 cs[2]* high decode address 0x434 page 132 cs[3]* low decode address 0x438 page 133 cs[3]* high decode address 0x43c page 133 boot cs* low decode address 0x440 page 133 boot cs* high decode address 0x444 page 133 address decode error 0x470 page 133 GT-96100A advanced communication controller revision 1.0 129 sdram configuration sdram configuration 0x448 page 134 sdram operation mode 0x474 page 135 sdram burst mode 0x478 page 135 sdram address decode 0x47c page 136 sdram parameters sdram bank0 parameters 0x44c page 137 sdram bank1 parameters 0x450 page 138 sdram bank2 parameters 0x454 page 138 sdram bank3 parameters 0x458 page 139 ecc ecc upper data 0x480 page 139 ecc lower data 0x484 page 139 ecc from memory 0x488 page 139 ecc calculated 0x48c page 139 ecc error report 0x490 page 140 device parameters device bank0 parameters 0x45c page 140 device bank1 parameters 0x460 page 141 device bank2 parameters 0x464 page 141 device bank3 parameters 0x468 page 141 device boot bank parameters 0x46c page 142 table 85: memory interface register map (continued) description offset page number GT-96100A advanced communication controller 130 revision 1.0 5.11.1 sdram and device address decode table 86: scs[0]* low decode address, offset: 0x400 bits field name function initial value 11:0 low sdram bank 0 is accessed when the decoded addresses are between low and high. 0x00 31:12 reserved 0x0 table 87: scs[0]* high decode address, offset: 0x404 bits field name function initial value 11:0 high sdram bank 0 is accessed when the decoded addresses are between low and high. 0x07 31:12 reserved 0x0 table 88: scs[1]* low decode address, offset: 0x408 bits field name function initial value 11:0 low sdram bank 1 is accessed when the decoded addresses are between low and high. 0x08 31:12 reserved 0x0 table 89: scs[1]* high decode address, offset: 0x40c bits field name function initial value 11:0 high sdram bank 1 is accessed when the decoded addresses are between low and high. 0x0f 31:12 reserved 0x0 GT-96100A advanced communication controller revision 1.0 131 table 90: scs[2]* low decode address, offset: 0x410 bits field name function initial value 11:0 low sdram bank 2 is accessed when the decoded addresses are between low and high. 0x10 31:12 reserved 0x0 table 91: scs[2]* high decode address, offset: 0x414 bits field name function initial value 11:0 high sdram bank 2 is accessed when the decoded addresses are between low and high. 0x17 31:12 reserved 0x0 table 92: scs[3]* low decode address, offset: 0x418 bits field name function initial value 11:0 low sdram bank 3 is accessed when the decoded addresses are between low and high. 0x18 31:12 reserved 0x0 table 93: scs[3]* high decode address, offset: 0x41c bits field name function initial value 11:0 high sdram bank 3 is accessed when the decoded addresses are between low and high. 0x1f 31:12 reserved 0x0 table 94: cs[0]* low decode address, offset: 0x420 bits field name function initial value 11:0 low device bank 0 is accessed when the decoded addresses are between low and high. 0xc0 31:12 reserved 0x0 GT-96100A advanced communication controller 132 revision 1.0 table 95: cs[0]* high decode address, offset: 0x424 bits field name function initial value 11:0 high device bank 0 is accessed when the decoded addresses are between low and high. 0xc7 31:12 reserved 0x0 table 96: cs[1]* low decode address, offset: 0x428 bits field name function initial value 11:0 low device bank 1 is accessed when the decoded addresses are between low and high. 0xc8 31:12 reserved 0x0 table 97: cs[1]* high decode address, offset: 0x42c bits field name function initial value 11:0 high device bank 1 is accessed when the decoded addresses are between low and high. 0xcf 31:12 reserved 0x0 table 98: cs[2]* low decode address, offset: 0x430 bits field name function initial value 11:0 low device bank 2 is accessed when the decoded addresses are between low and high. 0xd0 31:12 reserved 0x0 table 99: cs[2]* high decode address, offset: 0x434 bits field name function initial value 11:0 high device bank 2 is accessed when the decoded addresses are between low and high. 0xdf 31:12 reserved 0x0 GT-96100A advanced communication controller revision 1.0 133 table 100: cs[3]* low decode address, offset: 0x438 bits field name function initial value 11:0 low device bank 3 is accessed when the decoded addresses are between low and high. 0xf0 31:12 reserved 0x0 table 101: cs[3]* high decode address, offset: 0x43c bits field name function initial value 11:0 high device bank 3 is accessed when the decoded addresses are between low and high. 0xfb 31:12 reserved 0x0 table 102: boot cs* low decode address, offset: 0x440 bits field name function initial value 11:0 low boot bank is accessed when the decoded addresses are between low and high. 0xfc 31:12 reserved 0x0 table 103: boot cs* high decode address, offset: 0x444 bits field name function initial value 11:0 high boot bank is accessed when the decoded addresses are between low and high. 0xff 31:12 reserved 0x0 table 104: address decode error, offset: 0x470 bits field name function initial value 31:0 erraddr the addresses of accesses to invalid address ranges (those not in the range programmed in the sdram or device decode registers) are captured in this reg- ister. 0xffffffff GT-96100A advanced communication controller 134 revision 1.0 5.11.2 sdram configuration table 105: sdram configuration, offset: 0x448 bits field name function initial value 13:0 refintcnt refresh interval count value 0x0200 14 interleave bank interleaving control 0 - interleaving enabled 1 - interleaving disabled 0x0 15 rmw enable read modify write 0 - disabled 1 - enabled 0x0 16 stagref staggered refresh 0 - staggered refresh 1- non-staggered refresh 0x0 17 diseccer disable force ecc error 0x0 18 intoort interrupt one or two 0x0 19 dupcntl duplicate control pins 0 - do not duplicate 1 - duplicate control pins ? dmareq0* = sras* ? dmareq3* = scas* ? bypsoe* = dwr* 0x0 20 dupba duplicate bank addresses 0 - do not duplicate 1 - duplicate bank addresses ? dmareq[2]* = dadr[11] ? dmareq[1]* = banksel[1] 0x0 21 dupeot0 duplicate end of transfer 0 0 - do not duplicate 1 - duplicate end of transfer 0 ? dmareq[3]* = eot0 0x0 22 dupeot1 duplicate end of transfer 1 0 - do not duplicate 1 - duplicate end of transfer 1 ? ready* = eot1 0x0 23 regsdram registered sdram enable 0 - disable 1 - enable 0x0 GT-96100A advanced communication controller revision 1.0 135 24 dadr12sel dadr[12] pin select 0 - dadr[12] driven on adp[0] 1 - dadr[12] driven on dmareq[3]* 0x0 31:25 reserved 0x0 table 106: sdram operation mode, offset: 0x474 bits field name function initial value 2:0 sdramop special sdram mode select 000 - normal sdram mode 001 - nop command 010 - all banks precharge command 011 - mode register command enable 100 - cbr cycle enable 101,110, and 111 - reserved 0x0 31:3 reserved 0x0 table 107: sdram burst mode, offset: 0x478 bits field name function initial value 1:0 reserved must be 0x1. 0x1 2 burst_order 0 - linear 1 - sub-block 0x1 9:3 reserved must be 0x1. 0x1 10 arbitrationmode this bit controls the internal arbitration scheme employed by the memory control unit: 0 - normal arbitration mode (round robin: cpu -> pci -> dma ->...). 1 - cpu preferred arbitration mode (cpu - > pci -> cpu -> dma...). note: setting this bit is allowed only after the sdram was pro- grammed. 0x0 11 reserved must be 0. 0x0 31:12 reserved read only 0. x table 105: sdram configuration, offset: 0x448 (continued) bits field name function initial value GT-96100A advanced communication controller 136 revision 1.0 table 108: sdram address decode, offset: 0x47c bits field name function initial value 2:0 addrdecode sdram address decode see section 5.1.5 ?sdram address decode register (0x47c)? on page 104 for more information. 0x2 31:3 reserved 0x0 GT-96100A advanced communication controller revision 1.0 137 5.11.3 sdram parameters table 109: sdram bank0 parameters, offset: 0x44c bits field name function initial value 1:0 caslat cas latency identical for all sdram banks. 1 - 2 cycles 2 - 3 cycles 3 and 0 - reserved note: this value must be the same as in the srastoscas field. 0x1 2 flowthrough flow-through enable 0 - one sample 1 - no sample note: must be set to 0 if ecc or regis- tered sdram is enabled. 0x1 3 srasprchg sras precharge time 0 - 2 cycle 1 - 3 cycles 0x0 4 reserved must be set to 0. 0x0 5 64bitint 64-bit sdram interleaving 0 - 2 way bank interleaving 1 - 4 way bank interleaving 0x0 6 bankwidth width of sdram bank 0 - 32 (36) bit wide sdram 1 - 64 (72) bit wide sdram 0x0 7 bankloc 32-bit sdram bank location note: not applicable when using 64-bit sdrams. 0 - even, ad[31:0] 1 - odd, ad[63:32] 0x0 8 ecc ecc support for the bank. 0 - no ecc support 1 - ecc supported 0x0 9 bypass bypass enable to cpu 0 - no bypass 1 - bypass 0x0 10 srastoscas sras to scas delay 0 - 2 cycles 1 - 3 cycles note: this value must be the same as in the caslat field. 0x0 GT-96100A advanced communication controller 138 revision 1.0 11 sdramsize0 16 or 64/128/256 mbit sdram 0 - 16 mbit sdram 1 - 64/128/256 mbit sdram 0x0 12 reserved must be set to 0. 0x0 13 brstlen burst length 0 - burst of 8 1 - burst of 4 0x0 14 sdramsize1 256 mbit sdram support 0 - 16 or 64/128 mbit sdram 1 - 256mbit sdram 0x0 31:15 reserved 0x0 table 110: sdram bank1 parameters, offset: 0x450 bits field name function initial value 3:0 various fields function as in sdram bank0. 0x5 4 disable_refresh disable refresh of all sdram banks. 0 - do refresh 1 - disable refresh 0x0 14:5 various fields function as in sdram bank0. 0x0 31:15 reserved 0x0 table 111: sdram bank2 parameters, offset: 0x454 bits field name function initial value 3:0 various fields function as in sdram bank0. 0x5 4 treq*_enable uma total request pin enable. 0 - disable 1 - enable dmareq[3]*/scas* pin functions as a total request pin. 0x0 14:5 various fields function as in sdram bank0. 0x0 31:15 reserved 0x0 table 109: sdram bank0 parameters, offset: 0x44c (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 139 5.11.4 ecc table 112: sdram bank3 parameters, offset: 0x458 bits field name function initial value 3:0 various fields function as in sdram bank0. 0x5 4 reserved must be 0. 0x0 14:5 various fields function as in sdram bank0. 0x0 31:15 reserved 0x0 table 113: ecc upper data, offset: 0x480 bits field name function initial value 31:0 eccupdata bits[63:32] of the last data with an ecc error. 0x0 table 114: ecc lower data, offset: 0x484 bits field name function initial value 31:0 ecclodata bits[31:0] of the last data with an ecc error. 0x0 table 115: ecc from mem, offset: 0x488 bits field name function initial value 7:0 eccmem eight bits of ecc code read from memory. 0x0 31:8 reserved 0x0 table 116: ecc calculated, offset: 0x48c bits field name function initial value 7:0 ecccalc eight bits of ecc code calculated inside the GT-96100A. 0x0 31:8 reserved 0x0 GT-96100A advanced communication controller 140 revision 1.0 5.11.5 device parameters table 117: ecc error report, offset: 0x490 bits field name function initial value 1:0 eccerr number of ecc errors 00 - no errors 01 - one error detected and corrected 10 - two or more errors detected 11 - reserved 0x0 31:2 reserved 0x0 table 118: device bank0 parameters, offset: 0x45c bits field name function initial value 2:0 turnoff the number of cycles between the de- assertion of devoe* to a new ad bus cycle. note: an externally extracted signal which is the logical or between cstiming* and inverted devrw*. 0x7 6:3 acctofirst the number of cycles in a read access from the assertion of cs* to the cycle when the data is latched (by the external latches). extend the number of cycles via the ready* pin. 0xf 10:7 acctonext the number of cycles in a read access from the cycle that the first data is latched to the cycle that the next data is latched (in burst accesses). extend the number of cycles via the ready* pin. 0xf 13:11 aletowr the number of cycles from ale de- asserted to the assertion of wr*. 0x7 16:14 wractive the number of cycles wr* signals are active. extend the number of cycles via the ready* pin. 0x7 19:17 wrhigh the number of cycles between de-asser- tion and assertion of wr* signals. 0x7 GT-96100A advanced communication controller revision 1.0 141 21:20 devwidth device width 00 - 8 bits 01 - 16 bits 10 - 32 bits 11 - 64 bits 0x2 22 dmaflyby forwarded to bootcs* during flyby dma 0x1 23 devloc 32/16/8 bit device location 0 - even bank ? ad[31:0], ad[15:0], and ad[7:0] 1 - odd bank ? ad[63:32], ad[47:32], and ad[39:32] 0x0 24 reserved read only. 0x0 25 reserved must be 0. 0x0 29:26 dmaflyby forwarded to cs[3:0]* during flyby dma. 0xe 31:30 reserved must be 0. 0x0 table 119: device bank1 parameters, offset: 0x460 bits field name function initial value 31:0 various fields function as in device bank0. 0x386fffff table 120: device bank2 parameters, offset: 0x464 bits field name function initial value 31:0 various fields function as in device bank0. 0x386fffff table 121: device bank3 parameters, offset: 0x468 bits field name function initial value 31:0 various fields function as in device bank0. 0x38?fffff table 118: device bank0 parameters, offset: 0x45c (continued) bits field name function initial value GT-96100A advanced communication controller 142 revision 1.0 note: in case of bank3 or boot bank, bits [23:20] are shown as ??? because bits 21:20 are sampled at reset via dadr[4:3] to define the width of the boot device. table 122: device boot bank parameters, offset: 0x46c bits field name function initial value 31:0 various fields function as in device bank0. bits bits [29:26] and bit 22 are reserved. 14?fffff GT-96100A advanced communication controller revision 1.0 143 6. d ata i ntegrity GT-96100A supports: ? parity generation and checking on cpu and pci interfaces. ? ecc generation and checking on sdram interfaces. ? errors propagation between these the cpu, pci, and sdram interfaces. 6.1 sdram ecc the GT-96100A implements error checking and correction (ecc) on accesses to the sdram. it supports detection and correction of one data bit error, detection of two bits error, and detection of three or four bit errors, if residing in the same nibble. 6.1.1 ecc calculation each of the 64 data bits and eight check bits has a unique 8-bit ecc check code, as shown in table 123 . for example, data bit 12 has the check value of 01100001, and check bit 5 has the check value of 00100000. table 123: ecc code matrix check bit data bit ecc code bits number of 1s in 76543210 63 11001000 3 62 11000100 3 61 11000010 3 60 11000001 3 59 11110100 5 58 10001111 5 4 00010000 1 3 00001000 1 57 11100000 3 56 10110000 3 55 00001110 3 54 00001011 3 53 11110010 3 52 00011111 5 5 00100000 5 2 00000100 1 GT-96100A advanced communication controller 144 revision 1.0 51 10000110 1 50 01000110 3 49 00100110 3 48 00010110 3 47 00111000 3 46 00110100 3 45 00110010 3 44 00110001 3 43 10101000 3 42 10100100 3 41 10100010 3 40 10100001 3 39 10011000 3 38 10010100 3 37 10010010 3 36 10010001 3 35 01011000 3 34 01010100 3 33 01010010 3 32 01010001 3 31 10001010 3 30 01001010 3 29 00101010 3 28 00011010 3 27 10001001 3 26 01001001 3 25 00101001 3 24 00011001 3 23 10000101 3 table 123: ecc code matrix (continued) check bit data bit ecc code bits number of 1s in 76543210 GT-96100A advanced communication controller revision 1.0 145 22 01000101 3 21 00100101 3 20 00010101 3 19 10001100 3 18 01001100 3 17 00101100 3 16 00011100 3 15 01101000 3 14 01100100 3 13 01100010 3 12 01100001 3 11 11111000 5 10 01001111 5 7 10000000 1 0 00000001 1 9 01110000 3 8 11010000 3 7 00000111 3 6 00001101 3 5 11110001 5 4 00101111 5 6 01000000 1 1 00000010 1 3 10000011 3 2 01000011 3 1 00100011 3 0 00010011 3 table 123: ecc code matrix (continued) check bit data bit ecc code bits number of 1s in 76543210 GT-96100A advanced communication controller 146 revision 1.0 the GT-96100A calculates ecc by taking the even parity of ecc check codes of all data bits that are logic one. for example, if the 64 bit data is 0x45. the binary equivalent is 01000101. from table 123 , the required check codes are 00001101 (bit[6]), 01000011 (bit[2]) and 00010011 (bit[0]). bitwise xor of this check codes (even parity) result in ecc value of 01011101. on a write transaction to a 64-bit wide sdram, if ecc is enabled, the GT-96100A calculates the new ecc and writes it to the ecc bank along with the data that is written to the data bank. since the ecc calculation is based on a 64-bit data width, if the write transaction is smaller than 64 bits, the GT-96100A runs a read modify write sequence. for a read transaction from a 64-bit wide sdram, if ecc is enabled, the GT-96100A reads a 64-bit data and 8- bit ecc. it calculates ecc based on the 64-bit data and then compares it against the received ecc. the result of this comparison (bitwise xor between received ecc and calculated ecc) is called syndrome. if the syndrome is 00000000, both the received data and ecc are correct. if the syndrome is any other value, it is assumed either the received data or the received ecc are in error. if the syndrome contains a single 1, there is a single bit error in the ecc byte. for example, if the received data is 0x45, the calculated ecc is 01011101, as explained before. if the received ecc is 01010101, the resulting syn- drome is 00001000. table 123 shows that this syndrome corresponds to check bit 3. GT-96100A will not report nor correct this type of error. if the syndrome contains three or five 1?s, it indicates that there is at least one data bit error. for example, if the received data is 0x45, the calculated ecc is 01011101, as explained before. if the received ecc is 00011110, the resulting syndrome is 01000011. this syndrome includes three 1?s and it corresponds to data bit 2 as shown in table 123 . GT-96100A corrects the data by inverting data bit 2 (the corrected data is 0x41). if the result syndrome contains two 1?s, it indicates that there is a double-bit error. if the result syndrome contains four 1?s, it indicates a 4-bit error located in four consecutive bits of a nibble. if the result syndrome contains three or five 1?s and does not corresponds to any data bit, it indicates a triple-bit error within a nibble. these types of errors cannot be corrected. the GT-96100A reports an error but will not change the data. note: ecc is not supported in bypass mode (data must go through GT-96100A in order to be checked and cor- rected). 6.1.2 ecc error report if the GT-96100A identifies an ecc data bit error, it sets memerr bit in interrupt cause register (an interrupt is asserted if not masked). additionally, it stores error information in dedicated registers. ? the 64-bit data in ecc upper data and ecc lower data registers. ? the ecc byte read from memory in ecc from memory register. ? the calculated ecc byte in ecc calculated register. ? address bits[31:2] of the erroneous data in ecc address register. in bits[1:0] it reports whether it was a single data bit error or multiple data bits error. GT-96100A advanced communication controller revision 1.0 147 6.2 pci parity support the GT-96100A implements all parity features required by pci spec, including par, perr*, and serr* gener- ation and checking (also par64 in case of 64-bit pci configuration). as an initiator, the GT-96100A generates even parity on par signals for address phase and data phase of write transaction. it samples par on data phase of read transactions. if the GT-96100A detects bad parity and perren bit in status and command configuration register is set, it asserts perr*. as a target, the GT-96100A generates even parity on par signal for data phase of a read transaction. it samples par on address phase and data phase of write transactions. if the GT-96100A detects bad parity and perren bit in status and command configuration register is set, it asserts perr*. the GT-96100A asserts serr* if any of the following occur: ? detects a bad address parity as a target. ? detects a bad data parity on a write transaction as a master (detects perr* asserted). ? detects a bad data parity on a read transaction as a master. ? detects ecc error on read from sdram or device. ? performs master abort. ? detects target abort. serr* is asserted if serren bit in status and command configuration register is set to 1 and if serr* is not masked through serr mask register. note: for a description of the serr0* and serr1* registers, see table 418 and table 419 . 6.3 parity support for devices there is no dedicated logic in the GT-96100A to support devices parity. if devices parity checking is required, it can be implemented externally using ?511 devices and some logic for interrupt generation. still, the GT-96100A generates even parity on cpu sysadc lines during cpu read transaction from devices. 6.4 cpu parity support cpu parity is supported through sysadc lines. on write transactions, cpu drives even parity on sysadc. the GT-96100A samples the incoming data driven on sysad and the parity driven on sysadc. in case of parity error, the GT-96100A latches: ? the address in cpu error address register. ? the data in cpu error data register. ? the parity in cpu error parity register. on read transactions, cpu drives even parity on sysadc, in parallel to the data it drives on sysad. cpu parity errors are reported through cpuout interrupt bit in the interrupt cause register, and through syscmd[5] in case of read transaction. GT-96100A advanced communication controller 148 revision 1.0 notes: cpu error address register is also used to latch the address in case of cpu address decoding error. more over, cpuout interrupt bit is used both for cpu address decoding error as well as cpu parity error indication. in order for interrupt handler to distinguish between the two interrupts events, it needs to read cpu error data register and compare against its previous value. if register value changed, it implies it is a parity error. the cpuout interrupt bit is set in case of parity error only if sysadcvalid bit in cpu configuration register is set to 1. 6.5 data integrity flow 6.5.1 cpu writes to sdram and pci the GT-96100A samples the sysadc (cpu parity) lines when the cpu performs a write transaction to pci or sdram. parity checking is performed by the GT-96100A. if a parity error occurs, the GT-96100A latches the address, data, and parity lines, see section 6.6 ?register infor- mation? on page 150 . the GT-96100A also generates an interrupt (via interrupt*) to the cpu indicating a parity error has been detected on the cpu parity lines. in addition, the GT-96100A forces two ecc errors when writing the data to the sdram. this feature is config- ured through forceeccerr bit in sdram configuration register, see section 6.6 ?register information? on page 150 . this will make sure that when the data is read by another resource, the ecc bits will indicate erroneous data to the reading device. 6.5.2 cpu reads from sdram the GT-96100A samples the adp (sdram ecc) lines when the cpu performs a read transaction from the sdram. an ecc check is performed by the GT-96100A sdram interface. in case there is a 2-bit ecc error, the GT-96100A generates an interrupt to the cpu and drives the bus_err bit (syscmd[5]) to the cpu. the sysadc lines will not drive the wrong value, assuming the bus_err and the interrupt are sufficient indications for the cpu. in case of a single-bit ecc error, the default does not interrupt the cpu and the error is corrected. the gt- 96100a can be programmed to interrupt the cpu on single bit ecc errors, see section 6.6 ?register informa- tion? on page 150 . regardless, the data is corrected and then returned to the cpu. also, the address, data, ecc bits, and an indication for single or double ecc errors are latched in the GT-96100A ecc error report registers, see section 6.6 ?register information? on page 150 . 6.5.3 cpu reads from pci when the cpu reads data from the pci, the par signal (and par64 in case of 64-bit pci) is sampled. in case par does not match the data, an interrupt to the cpu is generated. GT-96100A advanced communication controller revision 1.0 149 6.5.4 pci writes to GT-96100A sdram when a pci master writes data to the GT-96100A?s sdram, the par signal (par64 in case of 64-bit pci) is sampled. in case par does not match the data, perr* is asserted on the pci bus and an interrupt to the cpu is generated. the ecc bits will not be intentionally damaged while being written to the sdram (GT-96100A will generate correct ecc to sdram based on the written data, ignoring the bad par indication). 6.5.5 pci reads from the sdram when a pci master reads data from the GT-96100A?s sdram, the GT-96100A samples the adp (sdram ecc) lines. an ecc check is performed by the GT-96100A. in case there is a 2-bit ecc error, the GT-96100A generates an interrupt to the cpu (and pci) and defaults to driving par with the correct value matching the data. this feature is configured, see section 6.6 ?register infor- mation? on page 150 , and par can be chosen to be driven with a value not matching the data. in case of a single ecc error, an interrupt to the cpu (and pci) is generated and the data is corrected and returned to the pci. par will drive a correct value, matching the data. in both cases the address, data, ecc bits, and an indication for single or double ecc errors are latched in the gt- 96100a ecc error report registers. 6.5.6 dma cycles there is no change in the implementation of data integrity during dma transfers from the gt-64120 device. if a parity/ecc error is detected during a dma transfer from the sdram or from the pci, an interrupt is generated. in case of a single-bit ecc error, the default does not interrupt the cpu and the error is corrected. the gt- 96100a can be programmed to interrupt the cpu on single-bit ecc errors, see section 6.6 ?register informa- tion? on page 150 . regardless, the data is corrected and then returned to the dma unit. also, the address, data, ecc bits, and an indication for single or double ecc errors are latched in the GT-96100A ecc error report reg- isters. GT-96100A advanced communication controller 150 revision 1.0 6.6 register information table 124 describes the registers used to implement parity and ecc in the GT-96100A. table 124: registers for implementing parity and ecc register offset description cpu error address 0x70 holds the lower 32 bits of the address during a parity error on sysadc (cpu write). 0x78 holds the upper 5 bits of the cpu address during a parity error on sysadc (cpu write). cpu error data 0x128 holds the lower 32 bits of the data during a parity error on sysadc (cpu write). 0x130 holds the upper 32 bits of the data during a parity error on sysadc (cpu write). cpu error parity 0x138 holds the sysadc lines when parity error is detected (cpu write). ecc error address 0x490 ? bits [31:2] holds the 30 msb of the address to the sdram when an ecc error is detected (cpu/pci/dma read from sdram). ? bit [1], if active, indicates that two or more ecc errors are detected. ? bit [0] - if active, indicates that a single bit ecc error is detected. ecc error data 0x480 holds the upper 32 bits of the data when an error is detected (cpu/pci/dma read from sdram). 0x484 holds the lower 32 bits of the data when an error is detected (cpu/pci/dma read from sdram). ecc from memory 0x488 holds the ecc read from memory when an error is detected. ecc calcula- tion 0x48c holds the value calculated by the GT-96100A as correct ecc. this value may be helpful during debug. force bad par on pci read bad ecc from sdram 0xc00, bit 26 0 - par always drives matching value (default). 1 - par will drive wrong value if ecc error detected. 0xc80, bit 26 force sdram ecc error on cpu writes with bad parity 0x448, bit 17 0 - sdram interface unit writes two ecc errors to the sdram (default). 1 - ecc will always be written correctly to the sdram. interrupt for 1 or 2 ecc errors 0x448, bit 18 0 - interrupt only if two ecc errors are detected (default). 1 - interrupt when one or two ecc errors are detected. GT-96100A advanced communication controller revision 1.0 151 6.7 cpu errors report registers table 125: cpu error address (low), offset: 0x070 bits field name function initial value 31:0 ilegloadd this register captures bits 31:0 of an illegal 36- bit address, or an address of a cpu write transaction with bad parity driven on sysadc. 0x0 table 126: cpu error address (high), offset: 0x078 bits field name function initial value 3:0 ileghiadd this register captures bits 35:32 of an illegal 36-bit address, or an address of a cpu write transaction with bad parity driven on sysadc. 0x0 31:4 reserved 0x0 table 127: cpu error data (low), offset: 0x128 bits field name function initial value 31:0 dataerr holds the lower 32 bits of the data during a parity error on sysadc (cpu write). 0xffffffff table 128: cpu error data (high), offset: 0x130 bits field name function initial value 31:0 dataerr holds the upper 32 bits of the data during a parity error on sysadc (cpu write). 0xffffffff table 129: cpu error parity, offset: 0x138 bits field name function initial value 7:0 parerr holds the sysadc lines when a parity error is detected (cpu write). 0xff 31:8 reserved reserved. 0x0 GT-96100A advanced communication controller 152 revision 1.0 7. pci i nterfaces the GT-96100A can be configured to have two 32-bit pci buses, or one 64-bit pci bus; all compliant with revi- sion 2.1 of the pci specification. both 3.3v and 5v operations are supported through the use of universal pci buffers. support for the i 2 o specifi- cation is also included. 7.1 reset configuration at reset, the GT-96100A can be configured to have one 64-bit pci interface or two 32-bit pci interfaces, see sec- tion 22. ?reset configuration? on page 452 . each pci interface can be either a master initiating a pci bus opera- tion or a target responding to a pci bus operation. note: when the GT-96100A is configured with two 32-bit pci interfaces, both interfaces are almost identical in behavior and structure. the only difference is that pci interface 1 (pci_1) does not support locked cycles and does not have a separate interrupt signal. if no reference is made to a particular pci interface, then the description in this section applies to both interfaces. 7.2 pci master operation when the cpu or the internal dma machine initiates a bus cycle to a pci device, the GT-96100A needs to decode the target address to determine which address space is being accessed. if the GT-96100A is configured as one 64-bit pci interface, then pci_0 registers are used for address comparison and remapping. if the GT-96100A is configured with two 32-bit pci buses, the address registers of both interfaces are used for comparison. based on the match results, either pci_0 or pci_1 becomes the master on the pci bus and translates the cycle into the appropriate pci bus cycle. supported master pci cycles are: ? memory read ? memory write ? memory read line ? memory read multiple ? memory write and invalidate ? i/o read ? i/o write ? configuration read ? configuration write ? interrupt acknowledge ? special cycle GT-96100A advanced communication controller revision 1.0 153 memory write and invalidate and memory read line cycles are carried out when the transaction accessing pci memory space requests a data transfer equal to the pci cache line size. in case the transfer initiator is a dma engine, the requested address must be cache line aligned. in case of write transaction, memory write and invali- date enable bit in the configuration command register must be set. when the pci cache line size is set equal to 0, the GT-96100A never issues memory write and invalidate or memory read line cycles. memory read multiple is carried out when the transaction accessing pci memory space requests a data transfer greater than the pci cache line size. as a master, the GT-96100A does not issue dual address cycles (dac) or lock cycles on the pci. the pci posted write buffer in the GT-96100A permits the cpu to complete cpu-to-pci memory writes even if the pci bus is busy. the posted data is written to the target pci device when the pci bus becomes available. 7.2.1 pci master cpu address space decode and translation local masters access the pci space through the pci_0/1 memory 0, pci_0/1 memory 1, and pci_0/1 i/o decod- ers in cpu address space. cpu accesses claimed by these decoders are translated into the appropriate pci cycles by the appropriate pci interface (pci_0 only in case of 64-bit pci interface). the address seen on the cpu bus is copied directly to the pci bus (unless the cpu-to-pci address remapping capability is enabled.) for example, if an access to 0x1200.0040 is programmed to be bridged as a memory read from pci, the active pci address for this cycle will be 0x1200.0040. 7.2.2 pci master cpu byte swapping all accesses to pci space by the cpu can have the data byte order swapped as the data moves through the gt- 96100a. byte swapping is turned on via the mbyteswap bit in the pci internal command register (0xc00.) when the GT-96100A is configured for 64-bit pci mode, byte swapping occurs across all eight byte lanes when the byteswap bit is set for pci_0. GT-96100A advanced communication controller 154 revision 1.0 7.2.3 pci master fifos if the GT-96100A is configured to have one 64-bit pci interface, then this interface includes a fifo of eight entries, each 64-bits wide (64 bytes total), see figure 25 . figure 25: pci master fifos in single 64-bit mode if the GT-96100A is configured to have two 32-bit pci interfaces, then each master interface includes its own fifo of eight entries, each 64-bits wide, see figure 26 . during writes to the pci interface, the target pci unit receives write data from the cpu interface or the dma unit. when the pci bus is granted, the pci master?s fifo delivers the write data to the target on the pci bus. 64-bit pci master fifo 8 entries by 64-bits (64 bytes total) pci master unit pci bus sysad write posting fifo 8 entries by 64-bits unidirectional sysad[63:0] cpu pci read path dma0/1 fifo 8 entries by 64-bits (64 bytes total) dma2/3 fifo 8 entries by 64-bits (64 bytes total) to intra-unit buses GT-96100A advanced communication controller revision 1.0 155 figure 26: pci master fifos in dual 32-bit mode 32-bit pci master fifo 0 8 entries by 64-bits (64 bytes total) pci master unit pci bus sysad write posting fifo 8 entries by 64-bits unidirectional sysad[63:0] cpu pci read path dma0/1 fifo 8 entries by 64-bits (64 bytes total) dma2/3 fifo 8 entries by 64-bits (64 bytes total) to intra-unit buses 32-bit pci master fifo 1 8 entries by 64-bits (64 bytes total) pci master unit pci bus GT-96100A advanced communication controller 156 revision 1.0 upon receiving the first 32- or 64-bit data from the cpu interface or dma unit, the pci master interface requests the pci bus, if the GT-96100A is not already parked. once granted, the appropriate write cycle is started on the pci bus. during reads, the pci master interface fifo receives read data from the pci bus and delivers it to the cpu inter- face or the dma unit. upon receiving the first word or doubleword from the pci target, the data is forwarded to the requesting unit (cpu interface or dma unit). the GT-96100A supports sub-block ordering during cpu reads, therefore if the original read request address is not aligned to a cache line boundary, then the first 32-bit word (or 64-bit double-word in case of a 64-bit pci interface) returned to the requesting unit is delayed until it is received from the pci target, since reads across the pci bus are linear. the GT-96100A internal architecture allows zero wait-state data transfer over the pci bus (irdy* continuously asserted) during both master reads and writes. 7.2.4 pci master dma the GT-96100A?s internal dma engines act as pci bus masters while transferring data to/from the pci bus. the dma engines only issue pci memory space read and write cycles. the type of cycle issued follows the same rules as for the cpu. the dma engines transfers data between pci devices using the on-chip dma fifos for temporary storage. note: see section 9. ?independent dma controllers (idma controllers)? on page 219 for a detailed descrip- tion of the dma engines. 7.2.5 pci master retry counter retrys detected by the pci master interface are normally handled transparently from the point of view of the cpu or dma engines. in some rare circumstances, however, a target device may retry the GT-96100A excessively (or forever.) use the retry counter to recover from this condition. every time the number of retrys equals the value in the retry counter, the GT-96100A aborts the cycle and sends an interrupt to the cpu. if the cycle was a read, unde- fined data is returned and the error bit is set within the data identifier. disable the retry counter by setting the retry count to zero. GT-96100A advanced communication controller revision 1.0 157 7.3 pci target interface the GT-96100A responds to the following pci cycles as a target device: ? memory read ? memory write ? memory read line ? memory read multiple ? memory write and invalidate ? i/o read ? i/o write ? configuration read ? configuration write ? locked read to pci_0 only ? locked write to pci_0 only the GT-96100A will not act as a target for interrupt acknowledge, special, and dual address cycles. these cycles are ignored.) 7.3.1 pci target fifos the GT-96100A incorporates dual 64-byte posted write/read prefetch buffers, per pci interface. these buffers allow full memory (ad) and pci bus concurrency. the dual fifos can operate in a ?ping-pong? fashion, each fifo alternating between filling and draining, see figure 27 and figure 28 . when the GT-96100A is the target of pci write cycles, data is first written to one of the fifos. when the first fifo fills up (64 bytes), the data is written to the destination from the first fifo while the second fifo is filled. this ?ping-pong? operation continues as long as data is received from the pci bus. the GT-96100A de-asserts trdy for 2 pci clocks while switching target fifos. occasionally, the pci target interface cannot drain the fifos (i.e. write to local memory) as fast as data is received. this occurs when access to memory is prevented (possibly by excessive cpu accesses) or when the target memory is particularly slow. in this case, the GT-96100A?s pci target interface de-asserts trdy until one of the fifos is empty again and might even issue a disconnect to the pci bus if reached timeout, see sec- tion 22. ?reset configuration? on page 452 . the target fifos are also used to align data bursts that do not start on 64-byte boundaries for more efficient pro- cessing by the GT-96100A?s memory subsystem. when an incoming burst passes a 64-byte boundary, the target fifos switch and the remainder of the burst (now aligned to a 64-byte boundary) fills the new fifo. trdy de- asserts for two pci clocks when the fifo switch occurs. GT-96100A advanced communication controller 158 revision 1.0 figure 27: pci target interface ?ping-pong? fifos target fifo 0 16 entries by 32-bits (8 entries by 64-bits in 64-bit mode) target fifo 1 16 entries by 32-bits (8 entries by 64-bits in 64-bit mode) target address dram and device unit to dram and devices pci bus GT-96100A advanced communication controller revision 1.0 159 figure 28: pci target interface fifos operational example 7.3.2 controlling burst length the GT-96100A?s memory interface is capable of maximum burst of eight data bursts to sdram or devices, regardless of the device width. this implies that if the device is 64-bits wide, it can burst up to 64 bytes in a sin- gle transaction. if the device is 32-bits wide it can burst up to 32 bytes per transaction and so on. the pci target is limited to requesting burst reads/writes from the memory interface that are not greater than the bursts supported by the controller. each pci target fifo corresponds to a single memory interface transaction. the pci target has a programmable fifo depth. the maxburst register (offset 0xc40) defines the fifo depth per each base address register. if the fifo depth is set to 16 (maxburst = 1) then the maximum burst is 64 bytes to/from the memory interface. if the fifo depth is eight (maxburst = 0) then a maximum burst of 32 bytes is supported on the memory interface. the system?s software must program the maxburst register properly. note: in order to support pci bursts to a 32-bit sdram or device, maxburst must be set to 0. this is also true for a 64-bit sdram programed to burst length of 4. maxburst may be used for performance optimization in systems with 64-bit wide memory. in some cases, it is sometimes preferred to keep the bursts short to allow cpu or dma to get more memory interface bandwidth. in this case, setting the maxburst value to 8 may be an appropriate strategy. fifo b (32-bytes) data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 dram/device unit fifo a (32-bytes) pci bus fifo b (32-bytes) data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 dram/device unit fifo a (32-bytes) pci bus fifo b (32-bytes) data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 dram/device unit fifo a (32-bytes) pci bus data flowing into fifo a from pci. no data flowing into dram yet. 8 words have been posted from pci. fifo a and b "flip". fifo b is now taking data from pci while fifo a drains into dram. 10 words haven been posted. pci bus has completed burst after 10 words. fifo a has drained and now fifo b is draining into dram. 64 bits 64 bits 64 bits 32/64 bits 32/64 bits 32/64 bits note: graphic shows only 8 of the 16 entries in the fifos (in 32-bit mode) GT-96100A advanced communication controller 160 revision 1.0 7.3.3 pci target read prefetching the target fifos are also used for read prefetch. the memory read (mr), memory read line (mrl), and memory read multiple (mrm) cycles are executed as prefetchable read cycles. the device/dram unit fills the target fifos as soon as it is determined that the pci request will be longer than a single word (based on how long frame* is asserted.) the ?aggressiveness? of the prefetch is controlled by the type of read command (mr/mrl/mrm) and the state of the bits for each of the read command types in the prefetch/max_burst register. by default, the only ?aggressive? prefetched read is the memory read multiple. both memory read and mem- ory read line commands are marked for aggressive prefetch via the prefetch/max_burst register. with aggres- sive prefetch, as soon as at least one word is delivered from the fifo to the pci bus, the pci slave requests from the device/dram unit to prefetch into the second fifo. note: when using aggressive prefetch, the upper address allowed to be read from the pci is last dram address minus 0x8. in a non-aggressive prefetch, read cycle data is prefetched into only one of the target fifos. data is not fetched into the second fifo until all the data from the first fifo is delivered to the pci bus. mr and mrl cycles are by default, non-aggressive prefetch. note: all three types of read commands will result in prefetch (multiple read cycles) on the device/dram bus unless frame* is only asserted for a single cycle. cycles to internal registers and configuration cycles are non-postable nor prefetchable. these cycles are always single word. note: if a pci master attempts to burst transaction to internal register, the GT-96100A disconnects after the first trdy*. 7.3.4 pci target address space decode and byte swapping the GT-96100A decodes accesses on the pci bus, for which it may be a target, by the values programmed into the base address registers (bars). there are two sets of bars for each pci interface: regular bars (in pci function 0) and swap bars (in pci function 1). accesses decoded by the regular bars are passed without modifying the data to or from the target memory device. accesses decoded by the swap bars are passed with to or from the target memory device after converting the endianess of the data (e.g. little-endian to big-endian). the GT-96100A uses a two stage decode process for accesses through the pci devices target interface. once a pci access is determined to be a ?hit? based on the bar comparison, the address is passed to the device unit for sub-decode. for example, pci_0 base address register 0 in function 0 (pci_0 bar0) decodes non-byte swapped accesses to the sdram controlled by either scs[0]* or scs[1]*. the GT-96100A then uses the values programmed into the scs[0]* low and scs[0] high decode registers to determine if the access is to the sdram in scs[0]* space. note: the second stage decoders are shared with the cpu, see figure 9 on page 79 . if the target address of a pci write transaction ?hits? based on the bar decode, then misses in the device unit, transaction is completed properly on the pci bus, but data is not written to memory. in case of read transaction, although there is no actual read from memory, transaction is completed properly on pci bus, but the data driven GT-96100A advanced communication controller revision 1.0 161 on the bus is undefined (unless timeout is reached first - retry termination). in both cases, memout bit in interrupt cause register is set (and interrupt is generated if not masked). 7.3.5 enhancing target interface performance the GT-96100A includes special performance tuning features for the pci target interface. the pci_0/1 timeout0 and timeout1 registers allow the designer to force the GT-96100A to wait either longer than normal, or shorter than normal, before issuing a retry/disconnect. the timeout0 value of pci device0 or device1 sets the number of clocks the device will wait for the first data of an access before issuing a retry. the timeout1 value sets the number of clocks the device will wait between subsequent data phases during an access before issuing a disconnect. the pci 2.1 specifications sets the maximum for both of these at 16 clocks (timeout0) and 8 clocks (timeout1) respectively. however, in many systems, especially those with long sdram latencies, it may be necessary to ?bend? these restrictions. 1 note: a value of 0x00 in timeout0 or timeout1 means "never timeout" if excessive retry/disconnect behavior occurs in the system, lengthen the timeout0/1 values. this behav- ior may result from excessive memory activity due to the cpu or dma engines and the pci interface failing to access the sdram within 16 clocks. the settings in the prefetch/max_burst registers provide another area for performance optimization. turning on aggressive prefetch for all read types results in a significant performance improvement, depending on the length and type of read commands. note: if a system uses many short reads from a pci, aggressive prefetch on speculative reads that are not used wastes bandwidth on the device/dram bus. 7.4 pci synchronization barriers the GT-96100A considers some cycles to be ?synchronization barrier? cycles. in such cycles, the GT-96100A confirms that at the end of the cycle there remains no posted data within the chip. these cycles can be initiated either from the pci slave side or the cpu side. the slave ?synchronization barrier? cycles are lock read (for pci_0 only) and configuration read. if there is no posted data within the device, the cycle ends normally. if after a retry period there is still posted data, the cycle is retried. until the original cycle ends, any other (different address/command) ?synchronization barrier? cycles are retried. lock read is a ?synchronization barrier? cycle that lasts during the entire lock period. for example, when the slave of pci_0 is locked, all configuration reads are retried. also, all cycles addressed to internal registers are retried until lock ends. the cpu interface treats i/o reads to pci and configuration reads as ?synchronization barrier? cycles as well. these reads are responded to once no posted data remains within the GT-96100A. 1. the pci specification also states that a master may not enforce target rules. in other words, even if the GT-96100A takes lo nger than 16 clocks to return the first data, the master must wait. GT-96100A advanced communication controller 162 revision 1.0 the GT-96100A provides the cpu with a simpler way to perform synchronization with pci buffers 1 . the cpu issues a read command to ?pci_0/1 sync barrier virtual? register to synchronize pci_0/1 buffers. the response dummy read completes once no posted data remains within the addressed pci interface. 7.5 pci master configuration the GT-96100A translates cpu read and write cycles into configuration cycles using pci configuration mecha- nism #1 (per the pci specification). mechanism #1 defines a way to translate the cpu cycles into both pci con- figuration cycles on the pci bus and accesses to the GT-96100A?s internal configuration registers. the GT-96100A includes two registers per pci device: configuration address (at offset 0xcf8 for pci0 and 0xcf0 for pci1) and configuration data (at offset 0xcfc for pci0 and 0xcf4 for pc1). the mechanism for access- ing configuration registers is to write a value into the configuration address register that specifies: ? pci bus number. ? the device on that bus. ? the function number within the device. ? the configuration register within that device/function being accessed. a subsequent read or write to the configuration data register (at 0xcfc/0xcf4) then causes the GT-96100A to translate that configuration address value to the requested cycle on the pci bus. if the busnum field in the configuration address register equals 0 but the devnum field is other than 0, a type0 access is performed that addresses a device attached to the local pci bus. if the busnum field in the configura- tion address register is other than 0, a type1 access is performed that addresses a device attached to a remote pci bus. the GT-96100A performs address stepping for pci configuration cycles. this allows for the use of the high- order pci ad signals as idsel signals through resistive coupling. 2 table 130 shows devnum to idsel mapping. 1. this mechanism is not compatible with the gt-64010a and gt-64011 devices. table 130: devnum to idsel mapping devnum[15:11] pad_0[31:11]/pad_1[31:11] 00001 0 0000 0000 0000 0000 0001 00010 0 0000 0000 0000 0000 0010 00011 0 0000 0000 0000 0000 0100 00100 0 0000 0000 0000 0000 1000 - - - - - - 10101 1 0000 0000 0000 0000 0000 00000, 10110 - 11111 0 0000 0000 0000 0000 0000 2. ?resistive coupling? is a fancy way of saying ?hook a resistor from adx to idsel? on a given device. look at the galileo-4pb backplane sche- matics for examples. GT-96100A advanced communication controller revision 1.0 163 the cpu accesses the GT-96100A?s internal configuration registers when the fields devnum and busnum in the configuration address register are equal to 0. the GT-96100A configuration registers are also accessed from the pci bus when the GT-96100A is a target responding to pci configuration read and write cycles. the cpu accesses the GT-96100A internal pci_1 configuration registers through pci_0 configuration address and data registers (0xcf8,0xcfc). for example, in order to access the GT-96100A?s pci_1 class code and rev id register, cpu software should write 0x80000088 to pci_0 configuration address register (0xcf8), and then read/write pci_0 configuration data register. cpu will use pci_1 configuration address register (0xcf0) and configuration data register (0xcf4) only in order to generate a configuration read/write transaction on pci_1 bus. the cpu interface unit cannot distinguish between an access to the GT-96100A?s pci configuration space and an access to an external pci device configuration space. both are accessed using an access to the GT-96100A?s internal space (i.e. configuration data register). the software engineer must keep this in mind, especially when byte swapping is enabled on the pci interface. in this case, internal configuration registers and configuration reg- isters in external devices will appear to have a different neediness. the configuration enable bit (configen) in the configuration address register must be set before the configura- tion data register is read or written. an attempt of cpu read a configuration register without this bit set, will result in undefined data returned on sassed bus 7.5.1 special cycles and interrupt acknowledge a special cycle is generated whenever the configuration data register is written to and the configuration address register has been previously written with 0 for busnum, 1f for devnum, 7 for functnum and 0 for reg- num. an interrupt acknowledge cycle is generated whenever the interrupt acknowledge (0xc34) register is read. 7.6 target configuration and plug and play the GT-96100A includes all of the required plug and play pci configuration registers. these registers, as well as the GT-96100A?s internal registers are accessible from both the cpu and the pci bus. the GT-96100A acts as a two function device when being configured from the pci bus. the base address regis- ters available in function 0 are used to decode accesses for which there is no byte swapping. function 1 is used to decode byte swapped addresses. all other registers are shared between function 0 and function 1, as shown in figure 29 . GT-96100A advanced communication controller 164 revision 1.0 figure 29: pci configuration header 7.6.1 plug and play base address register sizing systems adhering to the plug and play configuration standard determine the size of a base address register?s decode range by first writing 0xffff.ffff to the bar and then reading back the value contained in the bar. any bits that were unchanged (i.e., read back a zero) indicate that they cannot be set and are therefore not part of the address comparison. with this information, the size of the decode region can be determined. 1 the GT-96100A responds to bar sizing requests based on the values programmed into the bank size registers. these registers can be loaded automatically after reset from the system rom (see section 7.6.2 ?pci auto- load of configuration registers at reset? on page 164 ). 7.6.2 pci autoload of configuration registers at reset thirteen pci registers per pci interface can be automatically loaded after rst*. autoload mode is enabled by asserting the dadr[0] pin low on rst*. any pci transactions targeted for the GT-96100A must be retried while the loading of the pci configuration registers is in process. 1. refer to the pci specification for more information on the bar sizing process. device id vendor id rev id status command class code header line size latency bist scs[1:0] bar scs[3:2] bar cs[2:0] bar cs[3] & bootcs bar mem mapped internal bar io mapped internal bar reserved subsystem id subsystem vendor id expansion rom bar reserved min_gnt int. line int. pin max_lat 00h 04h 08h 0ch 10h 14h 18h 1ch 20h 24h 28h 2ch 30h 34h 38h 3ch function 0 header swap scs[1:0] bar swap scs[3:2] bar reserved swap cs[3] & bootcs bar reserved reserved reserved 00h 04h 08h 0ch 10h 14h 18h 1ch 20h 24h 28h 2ch 30h 34h 38h 3ch function 1 header reserved read only 0 aliased to function 0 register reserved cap.ptr GT-96100A advanced communication controller revision 1.0 165 the pci register values are loaded from the rom controlled by bootcs*. these register values are shown in table 131 for pci_0 and in table 132 for pci_1. although the configuration register information is typically stored in a boot rom device, a pld device can also be programmed to store this information. note: the pld should be programmed to support burst read cycles. table 131: pci_0 registers loaded at reset register offset boot device address command 0xc00 0x1fffff80 timeout & retry counters 0xc04 0x1fffff84 ras[1:0]* bank size 0xc08 0x1fffff88 ras[3:2]* bank size 0xc0c 0x1fffff8c cs[2:0]* bank size 0xc10 0x1fffff90 cs[3]* & boot cs* bank size 0xc14 0x1ffffff94 conf_en 0xc3c 0x1ffffff98 prefetch/max_burst 0xc40 0x1ffffff9c device and vendor id 0x000 0x1fffffa0 class code and revision id 0x008 0x1fffffa4 cache_line/latency 0x00c 0x1fffffa8 subsystem device and vendor id 0x02c 0x1fffffac interrupt pin and line 0x03c 0x1fffffb0 table 132: pci_1 registers loaded at reset register offset boot device address timeout & retry counters 0xc80 0x1fffffc0 counter 0xc84 0x1fffffc4 ras[1:0]* bank size 0xc88 0x1fffffc8 ras[3:2]* bank size 0xc8c 0x1fffffcc cs[2:0]* bank size 0xc90 0x1fffffd0 cs[3]* & boot cs* bank size 0xc94 0x1ffffffd4 conf_en 0xcbc 0x1ffffffd8 prefetch/max_burst 0xcc0 0x1ffffffdc device and vendor id 0x080 0x1fffffe0 class code and revision id 0x088 0x1fffffe4 cache_line/latency 0x08c 0x1fffffe8 GT-96100A advanced communication controller 166 revision 1.0 7.6.3 expansion rom functionality the GT-96100A implements the pci expansion rom as required by pc boot devices. the pci expansion rom functionality is enabled by strapping dadr[5] low at reset, see section 22. ?reset configuration? on page 452 . if the pci expansion rom is disabled, expansion rom register (offset 0x30 of pci configuration space) acts as reserved register and returns only 0 when read. when the expansion rom is enabled by the pin strapping option, the pci expansion rom bar appears in the GT-96100A?s pci_0 configuration header. however, the expansion rom decoder shares functionality with the scs[3]*/bootcs* resource. in normal operation (i.e., after the bios initialization is complete), the expansion rom is disabled via bit 0 in the expansion rom bar. during bios boot, however, the bios ?turns on? the expansion rom decoder by setting bit 0. when the expansion rom decoder is ?on? the following happens in pci_0: ? the pci target acts as if the timeout0 and timeout1 msbs are 1 (which means initial value of 0x8f and 0x87 respectively). this is done to allow for the long default access time from 8-bit boot roms. ? the device unit will bypass it's address decoding for all transactions from pci that are targeted to expansion rom or scs[3]*/bootcs*. all of these transactions assert cs[3] regardless of the actual address. ? the GT-96100A acts this way as long as bit[0] of expansion rom register is set to 1. the bios must clear this bit when it is done executing/probing the expansion rom. if the bios does not clear bit[0] of expansion rom bar, program this bit to 0 from cpu side. 7.7 pci bus/device bus/cpu clock synchronization the pci interface is designed to run asynchronously with respect to the ad and cpu buses. the synchronization delay between these two clock domains can be reduced by running the interfaces in syn- chronized mode. an example would be having the cpu/ad buses running at 66mhz and the pci bus running at a 33mhz frequency that was derived from the 66mhz. latency through the GT-96100A is reduced to a minimum when synchronized mode is selected. the synchroni- zation mode is set via the syncmode bits in the pci internal command registers (0xc00/0xc80). see section 2.4.2 ?pci read performance from sdram? on page 117 for a full description. note: tclk cycle must be smaller than pclk cycle by at least 1ns (t tclk < t pclk + 1ns). subsystem device and vendor id 0x0ac 0x1fffffec interrupt pin and line 0x0bc 0x1ffffff0 table 132: pci_1 registers loaded at reset (continued) register offset boot device address GT-96100A advanced communication controller revision 1.0 167 7.8 64-bit pci configuration the GT-96100A is configured to work as a 64-bit pci device if dadr[2] and frame1*/req64* pins are sam- pled low on reset, see section 22. ?reset configuration? on page 452 . note: the hold time for req64*, in respect to rst* rise, is 0, as required by the pci spec. when the GT-96100A is configured to a 64-bit pci, both master and target interfaces are configured to execute 64-bit transactions, whenever possible. the pci master interface always attempts to generate 64-bit transactions (asserts req64#) except for i/o or con- figuration transactions or when the required data is less than 64 bits. if the transaction target does not respond with ack64#, the master completes the transaction as a 32-bit transaction. the pci target interface always responds with ack64# to a 64-bit transaction, except for accesses to configura- tion space or internal registers. note: pclk1 must be tied to pclk0 on 64-bit pci configuration. 7.9 retry enable some applications require that the local mips cpu program the pci configuration registers in advance of other bus masters accessing them. in a pc add-in card application, for example, the mips cpu must set the device id, bar size requirements, etc. before the bios attempts to configure the card. the GT-96100A provides a mecha- nism by which the pci target interface retries all transactions until this configuration is complete. this prevents race conditions between the local mips processor and the bios. if dadr[6] pin is sampled low on reset, the GT-96100A pci target retries any transaction targeted to the gt- 96100a?s space. the GT-96100A stays in this retry mode until the stop retry bit in cpu configuration register (0x000) is set to 1. 7.10 locked cycles the GT-96100A locks a cache line (fixed at 32 bytes) in the local memory address space when responding to lock sequences on the pci bus. when a cache line is locked, any new pci access to an address within the locked cache line (except accesses ini- tiated by the lock owner) is terminated with retry. also, every access from cpu or dma to the locked cache line is on hold until the lock ends. although the GT-96100A does not support the lock* pin on pci_1, any access from pci_1 to a locked cache line is not completed until the lock ends. GT-96100A advanced communication controller 168 revision 1.0 7.11 hot-swap support the GT-96100A is compactpci hot swap capable. it supports the following hot swap device requirements: ? all pci outputs float when rst# is asserted. ? all the GT-96100A?s pci state machines are kept in their idle state while rst# is asserted. ? the GT-96100A pci interface does not leave it?s idle state until pci bus is in an idle state. if reset is de-asserted in the middle of a pci transaction, the GT-96100A pci interface stays in it?s idle state until pci bus is back in idle). ? the GT-96100A has no assumptions on clock behavior prior to it?s setup to the rising edge of rst#. ? the GT-96100A is tolerant of the 1v precharge voltage during insertion. ? the GT-96100A can be powered from early vcc. 7.12 pci power management support the GT-96100A is pci power management compliant. it contains the required configuration registers as shown in figure 30 . figure 30: power management registers the GT-96100A supports power management through reset configuration pins sdqm[1:0], each pin per each pci interface. if sampled high, power management is enabled. bit[4] of configuration status register is set, indicating the existence of a capability list. a capability list pointer register is implemented at offset 0x34, pointing to power management configuration registers implemented at offset 0x40 and 0x44. if sampled low, capability list is not supported and a capability pointer as well as pmc registers are reserved. power management registers are accessible from both cpu and pci. whenever pci_0 or pci_1 updates power state bits (bits[1:0] of pmcsr register), bit[21] of interrupt cause register is set (bit[21] of high interrupt cause register in case of pci_1 pmcsr configuration register) and an interrupt to cpu or pci is generated, if not masked by interrupt mask registers. when power management is enabled, bit[21] in the interrupt cause register is used as a power management interrupt rather than a doorbell interrupt, see interrupt section for details. note: the GT-96100A does not support it?s own power down. it only supports the software capability to power down the cpu or other on board devices. cap. ptr function 0 header offset 0x34 cap. id null ptr. pmc pmcsr bsr data power management capability GT-96100A advanced communication controller revision 1.0 169 7.13 pci interface restrictions 7.13.1 general 1. tclk cycle must be smaller than pclk cycle by at least 1ns (t tclk < t pclk + 1ns). 7.13.2 master 1. latency count, as specified in lattimer (pci configuration register 0x00c), must not be programmed to less than 6. 7.13.3 slave 1. the set bits in the bank size registers must be sequential. 2. when the slave is locked, in order to prevent a deadlock, all transactions to internal registers (i/o or memory cycles) are not supported (retry will be issued). 3. timeout0 value (pci internal register 0xc04) must not be programed to less than 2. 4. all pci reads result in prefetch read from the target device regardless of the bar prefetch bit value, unless frame* is asserted for a single clock cycle. 5. if 64-bit sdram/device is used that supports bursts of eight 64-bit words, the maxburst can only be set to 1 (i.e. 64 bytes). 7.14 pci control and configuration registers table 133: pci control and configuration register map description offset page number pci internal pci_0 command 0xc00 page 172 pci_1 command 0xc80 page 174 pci_0 time out & retry 0xc04 page 174 pci_1 time out & retry 0xc84 page 174 pci_0 scs[1:0]* bank size 0xc08 page 175 pci_1 scs[1:0]* bank size 0xc88 page 175 pci_0 scs[3:2]* bank size 0xc0c page 175 pci_1 scs[3:2]* bank size 0xc8c page 176 pci_0 cs[2:0]* bank size 0xc10 page 176 pci_1 cs[2:0]* bank size 0xc90 page 176 pci_0 cs[3]* & boot cs* bank size 0xc14 page 177 GT-96100A advanced communication controller 170 revision 1.0 pci internal (continued) pci_1 cs[3]* & boot cs* bank size 0xc94 page 177 pci_0 internal registers space size 0xc20 page 177 pci_1 internal registers space size 0xca0 page 178 pci_0 base address registers? enable 0xc3c page 178 pci_1 base address registers? enable 0xcbc page 179 pci_0 prefetch/max burst size 0xc40 page 179 pci_1 prefetch/max burst size 0xcc0 page 179 pci_0 scs[1:0]* base address remap 0xc48 page 180 pci_1 scs[1:0]* base address remap 0xcc8 page 180 pci_0 scs[3:2]* base address remap 0xc4c page 181 pci_1 scs[3:2]* base address remap 0xccc page 181 pci_0 cs[2:0]* base address remap 0xc50 page 182 pci_1 cs[2:0]* base address remap 0xcd0 page 182 pci_0 cs[3]* & boot cs* address remap 0xc54 page 182 pci_1 cs[3]* & boot cs* address remap 0xcd4 page 182 pci_0 swapped scs[1:0]* base address remap 0xc58 page 180 pci_1 swapped scs[1:0]* base address remap 0xcd8 page 180 pci_0 swapped scs[3:2]* base address remap 0xc5c page 181 pci_1 swapped scs[3:2]* base address remap 0xcdc page 181 pci_0 swapped cs[3]* & bootcs* base address remap 0xc64 page 183 pci_1 swapped cs[3]* & bootcs* base address remap 0xce4 page 183 pci_0 configuration address 0xcf8 page 183 pci_1 configuration address 0xcf0 page 184 pci_0 configuration data virtual register 0xcfc page 184 pci_1 configuration data virtual register 0xcf4 page 184 pci_0 interrupt acknowledge virtual register 0xc34 page 184 pci_1 interrupt acknowledge virtual register 0xc30 page 184 table 133: pci control and configuration register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 171 pci configuration pci_0 device and vendor id 0x000 page 185 pci_1 device and vendor id 0x080 page 185 pci_0 status and command 0x004 page 186 pci_1 status and command 0x084 page 186 pci_0 class code and revision id 0x008 page 188 pci_1 class code and revision id 0x088 page 188 pci_0 bist, header type, latency timer, cache line 0x00c page 188 pci_1 bist, header type, latency timer, cache line 0x08c page 189 pci_0 scs[1:0]* base address 0x010 page 190 pci_1 scs[1:0]* base address 0x090 page 190 pci_0 scs[3:2]* base address 0x014 page 191 pci_1 scs[3:2]* base address 0x094 page 191 pci_0 cs[2:0]* base address 0x018 page 191 pci_1 cs[2:0]* base address 0x098 page 192 pci_0 cs[3]* & boot cs* base address 0x01c page 192 pci_1 cs[3]* & boot cs* base address 0x09c page 192 pci_0 internal registers memory mapped base address 0x020 page 193 pci_1 internal registers memory mapped base address 0x0a0 page 193 pci_1 scs[1:0]* base address 0x090 page 190 pci_0 scs[3:2]* base address 0x014 page 191 pci_0 internal registers i/o mapped base address 0x024 page 193 pci_1 internal registers i/o mapped base address 0x0a4 page 193 pci_0 subsystem id and subsystem vendor id 0x02c page 194 pci_1 subsystem id and subsystem vendor id 0x0ac page 194 expansion rom base address register 0x030 page 194 pci_0 interrupt pin and line 0x03c page 195 pci_1 interrupt pin and line 0x0bc page 195 table 133: pci control and configuration register map (continued) description offset page number GT-96100A advanced communication controller 172 revision 1.0 7.14.1 pci internal registers pci configuration, function 1 pci_0 swapped scs[1:0]* base address 0x110 page 198 pci_1 swapped scs[1:0]* base address 0x190 page 198 pci_0 swapped scs[3:2]* base address 0x114 page 198 pci_1 swapped scs[3:2]* base address 0x194 page 199 pci_0 swapped cs[3]* & boot cs* base address 0x11c page 199 pci_1 swapped cs[3]* & boot cs* base address 0x19c page 200 table 134: pci_0 command, offset: 0xc00 bits field name function initial value 0 mbyteswap master byte swap. when set to zero, the GT-96100A pci master swaps the bytes of the incoming and outgoing pci data (swap the 8 bytes of a long-word). set to the same value sampled at reset into bit[12] of the cpu inter- face configuration regis- ter. 3:1 syncmode 1 indicates the ratio between tclk and pclk as follows: x00 - default mode. when the pclk ranges from dc to 66mhz. this mode works in all cases. note: use following settings for higher performance. 001 - when pclk is higher than or equal to half the tclk frequency (e.g. when tclk is 100mhz, syncmode can be set to 001 if the pci frequency is higher than or equal to 50mhz). 01x - when the two clocks are synchro- nized and pclk is higher than or equal to half of tclk frequency (e.g. tclk = 100mhz, pclk = 50mhz). 101 - when pclk is higher than or equal to a third of the tclk frequency but less than half of the tclk frequency. 11x - when the two clocks are synchro- nized and pclk is higher than or equal to third of the tclk frequency but less than half of the tclk frequency. 0x0 table 133: pci control and configuration register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 173 7:4 reserved read only. 0x0 9:8 reserved must be 0. 0x0 10 mwordswap* master word swap when set to 1, the GT-96100A pci master swaps the words of the incoming and out- going pci data (swaps the 2 words of a long-word). note: not supported when using a 64- bit pci interface. 0x0 11 swordswap* slave word swap when set to 1, the GT-96100A pci slave swaps the words of the incoming and out- going pci data (swap the 2 words of a long-word), if there is an address hit in one of sdram or devices bars. note: not supported when using a 64- bit pci interface. 0x0 12 ssbwordswap* slave swap bar word swap. when set to 1, the GT-96100A pci slave swaps the words of the incoming and out- going pci data (swap the 2 words of a long-word), if address hit in one of sdram or devices swap bars. note: not supported when using a 64- bit pci interface. 0x0 15:13 reserved must be 0. 0x0 16 sbyteswap slave byte swap. when set to zero, the GT-96100A pci slave swaps the bytes of the incoming and outgoing pci data (swap the 8 bytes of a long-word). set to the same value as sampled at reset into bit[12] of the cpu inter- face configuration regis- ter. 31:17 reserved must be 0. 0x0 1. regardless of the selected syncmode, pclk frequency must be smaller than tclk frequency by at least 1mhz. table 134: pci_0 command, offset: 0xc00 (continued) bits field name function initial value GT-96100A advanced communication controller 174 revision 1.0 note: see also section 7.6.3 ?expansion rom functionality? on page 166 table 135: pci_1 command, offset: 0xc80 bits field name function initial value 31:0 various same as for the pci_0 command. 0x0 1 1. for bit 16, set to the same value as sampled at reset into bit[12] of the cpu interface configuration register. table 136: pci_0 time out & retry, offset: 0xc04 bits field name function initial value 7:0 timeout0 specifies in pci clock units the number of clocks that the GT-96100A, as a slave, holds the pci bus before the generation of retry termination. a value of 0x00 means "never timeout". used for the first data transfer. 0x0f 15:8 timeout1 specifies in pci clock units the number of clocks that the GT-96100A, as a slave, holds the pci bus before the generation of disconnect termination. a value of 0x00 means "never timeout". used for data transfers following the first data. 0x07 23:16 retryctr specifies the number of retries of the gt- 96100a master. the GT-96100A gener- ates an interrupt when this timer expires. a value of 0x00 means ?retry forever?. the number in retryctr does not include the first access of the transaction. 0x0 31:24 reserved 0x0 table 137: pci_1 time out & retry, offset: 0xc84 bits field name function initial value 31:0 various same as for pci_0 time out and retry. 0x070f GT-96100A advanced communication controller revision 1.0 175 table 138: pci_0 scs[1:0] bank size, offset: 0xc08 bits field name function initial value 11:0 reserved read only. 0x0 31:12 banksize specifies the scs[1:0]* address mapping in conjunction with the scs[1:0]* base address register. 0 - the corresponding bit in the address and in the base address must be equal in order to have a hit. 1 -the corresponding bit in the address is a ?don?t-care?. for example, bit 12 set to 1 indicates that the scs[1:0]* size is 8kbytes. the set bits in the bank size must be sequential (e.g. 000...001, 000...011, 000...111 are correct values, whereas 000...010 and 000...100 are not). 0x00fff table 139: pci_1 scs[1:0]* bank size, offset: 0xc88 bits field name function initial value 31:0 various same as for pci_0 scs[1:0]* bank size. 0x00fff000 table 140: pci_0 scs[3:2]* bank size, offset: 0xc0c bits field name function initial value 11:0 reserved read only. 0x0 31:12 banksize specifies the scs[3:2]* address mapping in conjunction with the scs[3:2]* base address register. 0 -the corresponding bit in the address and in the base address must be equal in order to have a hit. 1 - the corresponding bit in the address is a ?don?t-care?. for example, bit 12 set to 1 indicates that the scs[3:2]* size is 8kbytes. the set bits in the bank size must be sequential (e.g. 000...001, 000...011, 000...111 are correct values, whereas 000...010 and 000...100 are not). 0x00fff GT-96100A advanced communication controller 176 revision 1.0 table 141: pci_1 scs[3:2]* bank size, offset: 0xc8c bits field name function initial value 31:0 various same as for pci_0 scs[3:2]* bank size. 0x00fff000 table 142: pci_0 cs[2:0]* bank size, offset: 0xc10 bits field name function initial value 11:0 reserved read only 0x0 31:12 banksize specifies the cs[2:0]* address mapping in conjunction with the cs[2:0]* base address register. 0 - the corresponding bit in the address and in the base address must be equal in order to have a hit. 1 - the corresponding bit in the address is a ?don?t-care?. for example, bit 12 set to ?1? indicates that the cs[2:0]* size is 8kbytes. the set bits in the bank size must be sequential (e.g. 000...001, 000...011, 000...111 are correct values, whereas 000...010 and 000...100 are not). 0x01fff table 143: pci_1 cs[2:0]* bank size, offset: 0xc90 bits field name function initial value 31:0 various same as for pci_0 cs[2:0]* bank size. 0x01fff000 GT-96100A advanced communication controller revision 1.0 177 table 144: pci_0 cs[3]* and boot cs* bank size, offset: 0xc14 bits field name function initial value 11:0 reserved read only. 0x0 31:12 banksize specifies the cs[3]* and boot cs* address mapping in conjunction with the cs[3]* and boot cs* base address regis- ter. 0 - the corresponding bit in the address and in the base address must be equal in order to have a hit. 1 - the corresponding bit in the address is a ?don?t-care?. for example, bit 12 set to ?1? indicates that the cs[3]*/ boot cs* size is 8kbytes. the set bits in the bank size must be sequen- tial (e.g. 000...001, 000...011, 000...111 are correct values, whereas 000...010 and 000...100 are not). 0x00fff table 145: pci_1 cs[3]* and boot cs* bank size, offset: 0xc94 bits field name function initial value 31:0 various same as for pci_0 cs[3]* and boot cs* bank size. 0x00fff000 table 146: pci_0 internal registers space size, offset: 0xc20 bits field name function initial value 11:0 reserved read only. 0x0 31:12 banksize specifies the internal registers address mapping in conjunction with the internal registers base address register. 0 - the corresponding bit in the address and in the base address must be equal in order to have a hit. 1 - the corresponding bit in the address is a ?don?t-care?. for example, bit 12 set to ?1? indicates that the internal registers space size is 8kbytes. the set bits in the banksize must be sequential (e.g. 000...001, 000...011, 000...111 are correct values, whereas 000...010 and 000...100 are not). 0x00000 GT-96100A advanced communication controller 178 revision 1.0 table 147: pci_1 internal registers space size, offset: 0xca0 bits field name function initial value 31:0 various same as for pci_0 internal registers space size. 0x00000000 table 148: pci_0 base address registers? enable, offset: 0xc3c bits field name function initial value 0 swcs[3]_&_boot_c sen controls address matching with swapped cs[3]* & boot cs* base/size. 0 - enable 1 - disable 0x1 1 swscs[3:2]en controls address matching with swapped scs[3:2]* base/size. 0 - enable 1 - disable 0x1 2 swscs[1:0]en controls address matching with swapped scs[1:0]* base/size. 0 - enable 1 - disable 0x1 3 intioen controls address matching with internal registers i/o mapped base/size. 0 - enable 1 - disable 0x1 4 intmemen controls address matching with internal registers memory mapped base/size. 0 - enable 1 - disable 0x0 5 cs[3]*_&_boot_cse n controls address matching with cs[3]* & boot cs* base/size. 0 - enable 1 - disable 0x0 6 cs[2:0]en controls address matching with cs[2:0]* base/size. 0 - enable 1 - disable 0x0 7 scs[3:2]en controls address matching with scs[3:2]* base/size. 0 - enable 1 - disable 0x0 GT-96100A advanced communication controller revision 1.0 179 note: the GT-96100A prevents disabling both memory mapped base/size address matching and i/o mapped base/size address matching at the same time (bits 3 and 4 cannot simultaneously be set to 1). 8 scs[1:0]en controls address matching with scs[1:0]* base/size. 0 - enable 1 - disable 0x0 31:9 reserved 0x0 table 149: pci_1 base address registers? enable, offset: 0xcbc note: reserved if configured for only pci_0) bits field name function initial value 31:0 various same as for pci_0 base address regis- ters? enable. 0x0f table 150: pci_0 prefetch/max burst size, offset: 0xc40 bits field name function initial value 0 dram0maxbrst scs[1:0]* max burst length 0x0 1 dram1maxbrst scs[3:2]* max burst length 0x0 2 dev0maxbrst cs[2:0]* max burst length 0x0 3 dev1maxbrst cs[3]* & boot cs* max burst length 0x0 4 rdmempref read memory prefetch 0x0 5 rdlnpref read line prefetch 0x0 6 rdmulpref read multiple prefetch 0x1 31:7 reserved 0x0 table 151: pci_1 prefetch/max burst size, offset: 0xcc0 note: reserved if configured for only pci_0. bits field name function initial value 31:0 various same as for pci_0 prefetch/max burst size. 0x040 table 148: pci_0 base address registers? enable, offset: 0xc3c (continued) bits field name function initial value GT-96100A advanced communication controller 180 revision 1.0 table 152: pci_0 scs[1:0]* base address remap, offset: 0xc48 bits field name function initial value 11:0 reserved read only. 0x0 31:12 dram0remap scs[1:0]* memory address remap from pci side. reserved if this bar is disabled through pci_0 base address registers? enable. 0x0 table 153: pci_1 scs[1:0]* base address remap, offset: 0xcc8 note: reserved if configured for only pci_0. bits field name function initial value 11:0 reserved read only. 0x0 31:12 dram0remap scs[1:0]* memory address remap from pci side reserved if this bar is disabled through pci_1 base address registers? enable. 0x0 table 154: pci_0 swapped scs[1:0]* base address remap, offset: 0xc58 bits field name function initial value 11:0 reserved read only. 0x0 31:12 swapped_dram0_ remap swapped scs[1:0]* memory address remap from pci side reserved if this bar is disabled through pci_0 base address registers? enable. 0x0 table 155: pci_1 swapped scs[1:0]* base address remap, offset: 0xcd8 note: reserved if configured for only pci_0. bits field name function initial value 11:0 reserved read only. 0x0 31:12 swapped_ dram0remap swapped scs[1:0]* memory address remap from pci side reserved if this bar is disabled through pci_1 base address registers? enable. 0x0 GT-96100A advanced communication controller revision 1.0 181 table 156: pci_0 scs[3:2]* base address remap, offset: 0xc4c bits field name function initial value 11:0 reserved read only. 0x0 31:12 dram1remap scs[3:2]* memory address remap from pci side reserved if this bar is disabled through pci_0 base address registers? enable. 0x01000 table 157: pci_1 scs[3:2]* base address remap, offset: 0xccc note: reserved if configured for only pci_0. bits field name function initial value 11:0 reserved read only. 0x0 31:12 dram1remap scs[3:2]* memory address remap from pci side reserved if this bar is disabled through pci_1 base address registers? enable. 0x01000 table 158: pci_0 swapped scs[3:2]* base address remap, offset: 0xc5c bits field name function initial value 11:0 reserved read only. 0x0 31:12 swapped_ dram1remap swapped scs[3:2]* memory address remap from pci side reserved if this bar is disabled through pci_0 base address registers? enable. 0x01000 table 159: pci_1 swapped scs[3:2]* base address remap, offset: 0xcdc (reserved if configured for only pci_0) bits field name function initial value 11:0 reserved read only. 0x0 31:12 swapped_ dram1remap swapped scs[3:2]* memory address remap from pci side reserved if this bar is disabled through pci_1 base address registers? enable. 0x01000 GT-96100A advanced communication controller 182 revision 1.0 table 160: pci_0 cs[2:0]* base address remap, offset: 0xc50 bits field name function initial value 11:0 reserved read only. 0x0 31:12 dev0remap cs[2:0]* memory address remap from pci side reserved if this bar is disabled through pci_0 base address registers? enable. 0x1c000 table 161: pci_1 cs[2:0]* base address remap, offset: 0xcd0 note: reserved if configured for only pci_0. bits field name function initial value 11:0 reserved read only. 0x0 31:12 dev0remap cs[2:0]* memory address remap from pci side reserved if this bar is disabled through pci_1 base address registers? enable. 0x1c000 table 162: pci_0 cs[3]* & bootcs* base address remap, offset: 0xc54 bits field name function initial value 11:0 reserved read only. 0x0 31:12 dev1remap cs[3]* & bootcs* memory address remap from pci side reserved if this bar is disabled through pci_0 base address registers? enable. 0x1f000 table 163: pci_1 cs[3]* & bootcs* base address remap, offset: 0xcd4 note: reserved if configured for only pci_0. bits field name function initial value 11:0 reserved read only. 0x0 31:12 dev1remap cs[3]* & bootcs* memory address remap from pci side reserved if this bar is disabled through pci_1 base address registers? enable. 0x1f000 GT-96100A advanced communication controller revision 1.0 183 table 164: pci_0 swapped cs[3]*& bootcs* base address remap, offset: 0xc64 bits field name function initial value 11:0 reserved read only. 0x0 31:12 swapped_ dev1remap swapped cs[3]* & bootcs* memory address remap from pci side reserved if this bar is disabled through pci_0 base address registers? enable. 0x1f000 table 165: pci_1 swapped cs[3]* & bootcs* base address remap, offset: 0xce4 note: reserved if configured for only pci_0. bits field name function initial value 11:0 reserved read only. 0x0 31:12 swapped_ dev1remap swapped cs[3]* & bootcs* memory address remap from pci side reserved if this bar is disabled through pci_1 base address registers? enable. 0x1f000 table 166: pci_0 configuration address, offset: 0xcf8 bits field name function initial value 1:0 reserved read only. 0x0 7:2 regnum indicates the register number. 0x00 10:8 functnum indicates the function type. 0x0 15:11 devnum indicates the device number. 0x00 23:16 busnum indicates the bus number. 0x00 30:24 reserved read only. 0x0 31 configen when set, an access to the configuration data register is translated into a configu- ration or special cycle on the pci bus. 0x0 GT-96100A advanced communication controller 184 revision 1.0 table 167: pci_0 configuration data, offset: 0xcfc bits field name function initial value 31:0 config the data is transferred to/from the pci bus when the cpu accesses this register and the configen bit in the configuration address register is set. a cpu access to this register means the GT-96100A performs a configuration or special cycle on the pci bus. 0x000 table 168: pci_1 configuration address, offset: 0xcf0 note: reserved if configured for only pci_0. bits field name function initial value 31:0 various same as for pci_0 configuration address. 0x000 table 169: pci_1 configuration data, offset: 0xcf4 note: reserved if configured for only pci_0. bits field name function initial value 31:0 config same as for pci_0 configuration data. 0x000 table 170: pci_0 interrupt acknowledge virtual register, offset: 0xc34 bits field name function initial value 31:0 intack_0 a cpu read access to this register forces an interrupt acknowledge cycle on pci_0. read only. 0x0 table 171: pci_1 interrupt acknowledge virtual register, offset: 0xc30 bits field name function initial value 31:0 intack_1 a cpu read access to this register forces an interrupt acknowledge cycle on pci_1. read only. 0x0 GT-96100A advanced communication controller revision 1.0 185 7.14.2 pci configuration registers all pci configuration registers are located at their standard offset when accessed from their corresponding pci bus. for example, if a master on pci_0 performs a pci configuration cycle on pci_0?s status and command reg- ister, the register is located at 0x004. likewise, if a master on pci_1 performs a pci configuration cycle on pci_1?s status and command register, the register is located at 0x004. on the other hand, if a master on pci_0 performs a pci configuration cycle on pci_1?s status and command register, the register is located at 0x084. likewise, if a master on pci_1 performs a pci configuration cycle on pci_0?s status and command register, the register is located at 0x084. if the cpu masters pci configuration cycles, pci_0 configuration registers are located at their standard offsets and pci_1 configuration registers are located at 0x80 + standard offset. note: all pci_1 configuration registers are reserved if the GT-96100A is configured for only pci_0 opera- tion. table 172: pci_0 device and vendor id, offset: 0x000 from pci_0 or cpu; 0x080 from pci_1 bits field name function initial value 15:0 venid provides the GT-96100A?s manufacturer. read only. 0x11ab 31:16 devid provides the unique GT-96100A pci device0 id number. read only. 0x9653 table 173: pci_1 device and vendor id, offset: 0x080 from pci_0 or cpu; 0x000 from pci_1 bits field name function initial value 31:0 various same as for pci_0 device and venid 0x965311ab GT-96100A advanced communication controller 186 revision 1.0 table 174: pci_0 status and command, offset: 0x004 from pci_0 or cpu; 0x084 from pci_1 bits field name function initial value 0 ioen controls the GT-96100A?s response to i/o accesses. 0 - disable 1 - enable 0x0 1 memen controls the GT-96100A?s response to memory accesses. 0 - disable 1 - enable 0x0 2 masen controls the GT-96100A?s ability to act as a master on the pci bus. 0 - disable 1 - enable 0x0 3 reserved read only. 0x0 4 memwrinv controls the GT-96100A?s ability to gener- ate memory write and invalidate com- mands on the pci bus. 0 - disable 1 - enable 0x0 5 reserved read only. 0x0 6 perren controls the GT-96100A?s ability to respond to parity errors on the pci by asserting the perr* pin. 0 - disable 1 - enable 0x0 7 reserved read only. 0x0 8 serren controls the GT-96100A?s ability to assert the serr* pin. 0 - disable 1 - enable 0x0 19:9 reserved read only. 0x0 20 caplist capability list support sampled at rst* via sdqm[0]* pin. 21 66mhzen 66mhz capable. the GT-96100A pci interface is capable of running at 66mhz regardless of this bit value. sampled at reset via the dadr[9] pin. 22 reserved read only. 0x0 GT-96100A advanced communication controller revision 1.0 187 note: for bits 24 and 28 to 31, the user cannot set the bit. the user can only clear the bit by writing 1 to it. 23 tarfastbb read only. indicates that the GT-96100A is capable of accepting fast back-to-back transactions on the pci bus. 0x1 24 datapardet this bit is set by the GT-96100A when it detects a data parity error during master operation. 0x0 26:25 devseltim these pins indicate that the GT-96100A?s devsel timing (medium), per the pci stan- dard. 0x1 read only 27 reserved read only. 0x0 28 tarabort this bit is set upon target abort. 0x0 29 masabort this pin is set upon master abort. 0x0 30 syserr this pin is set upon system error. 0x0 31 detparerr this pin is set upon detection of a parity error in master or slave operations. 0x0 table 175: pci_1 status and command, offset: 0x084 from pci_0 or cpu; 0x004 from pci_1 bits field name function initial value 19:0 various same as for pci_0 status and command 20 caplist capability list support sampled at rst* via sdqm[1]* pin. 31:21 caplist same as for pci_0 status and command table 174: pci_0 status and command, offset: 0x004 from pci_0 or cpu; 0x084 from pci_1 (continued) bits field name function initial value GT-96100A advanced communication controller 188 revision 1.0 table 176: pci_0 class code and revision id, offset: 0x008 from pci_0 or cpu; 0x088 from pci_1 bits field name function initial value 7:0 revid indicates the GT-96100A?s pci_0 revision number. 0x03 15:8 reserved read only. 0x0 23:16 subclass indicates the GT-96100A?s subclass. 0x00 - host bridge device 0x80 - memory device 0x80 31:24 baseclass indicates the GT-96100A?s base class. 0x02 - network controller 0x05 - memory device depends on value sam- pled at reset on bank- sel[0]. table 177: pci_1 class code and revision id, offset: 0x088 from pci_0 or cpu; 0x008 from pci_1 bits field name function initial value 31:0 various same as for pci_0 class code and revi- sion id depends on value sam- pled at reset on bank- sel[0]. table 178: pci_0 bist, header type, latency timer, cache line, offset: 0x00c from pci_0 or cpu; 0x08c from pci_1 bits field name function initial value 7:0 cacheline specifies the GT-96100A?s cache line size. 0x00 15:8 lattimer specifies, in units of pci bus clocks, the value of the GT-96100A?s latency timer. 0x00 23:16 headtype specifies the layout of bytes 10h through 3fh. 0x00 31:24 bist built in self test reserved 0x00 GT-96100A advanced communication controller revision 1.0 189 the bist field is reserved and is hardwired to 0. device and vendor id (0x000), class code and revision id (0x008), and header type (0x00e) fields are read only from the pci bus. these fields can be modified and read via the cpu bus. note: for more information on these fields, refer to the pci specification. access of pci masters to sdram banks, devices and internal space is achieved once there is a match between the address presented over the pci bus and the space defined by the respective base/size register pair. the gt- 96100a incorporates three swapped base address registers for scs[1:0]*, scs[3:2]*, cs[3]*, and bootcs*. when the address matches a swapped base address register x, the data transferred will undergo the opposite to what is indicated by the byteswap bit (bit[0] of 0xc00). e.g. using this mechanism, one could write data directly to sdram and read it byte-swapped without cpu processing. note: the address must not match its respective non-swap base address register. table 179: pci_1 bist, header type, latency timer, cache line, offset: 0x08c from pci_0 or cpu; 0x00c from pci_1 bits field name function initial value 31:0 various as in pci_0 bist, header type, latency timer, cache line. 0x00 GT-96100A advanced communication controller 190 revision 1.0 the size registers cannot define a zero size space. in order to enable the system designer to use addresses which are within a certain space without having the GT-96100A respond to these addresses, a base address enable reg- ister is incorporated. a disabled space will not trigger a device response if the address falls within the space defined by its base/size register pair. table 180: pci_0 scs[1:0]* base address, offset: 0x010 from pci_0 or cpu; 0x090 from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 2:1 type type read only. 0x0 3 prefetch prefetch 0x1 11:4 reserved read only. 0x0 31:12 base defines the address assignment of scs[1:0]*, see table 138 . reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x00000 table 181: pci_1 scs[1:0]* base address, offset: 0x090 from pci_0 or cpu; 0x010 from pci_1 bits field name function initial value 31:0 various same as for pci_0 scs[1:0]* base address 0x08 GT-96100A advanced communication controller revision 1.0 191 table 182: pci_0 scs[3:2]* base address, offset: 0x014 from pci_0 or cpu; 0x094 from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 2:1 type type read only. 0x0 3 prefetch prefetch 0x1 11:4 reserved read only. 0x0 31:12 base defines the address assignment of scs[3:2]*, see table 140 . reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x01000 table 183: pci_1 scs[3:2]* base address, offset: 0x094 from pci_0 or cpu; 0x014 from pci_1 bits field name function initial value 31:0 various same as for pci_0 scs[3:2]* base address. 0x01000008 table 184: pci_0 cs[2:0]* base address, offset: 0x018 from pci_0 or cpu; 0x098 from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 2:1 type type read only. 0x0 3 prefetch prefetch 0x0 11:4 reserved read only. 0x0 31:12 base defines the address assignment of cs[2:0]*, see table 142 . reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x1c000 GT-96100A advanced communication controller 192 revision 1.0 table 185: pci_1 cs[2:0]* base address, offset: 0x098 from pci_0 or cpu; 0x018 from pci_1 bits field name function initial value 31:0 various same as for pci_0 cs[2:0]* base address ox1c000000 table 186: pci_0 cs[3]* and boot cs* base address, offset: 0x01c from pci_0 or cpu; 0x09c from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 2:1 type type read only. 0x0 3 prefetch prefetch 0x0 11:4 reserved read only. 0x0 31:12 base defines the address assignment of cs[3]* and boot cs*, see table 144 . reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x1f000 table 187: pci_1 cs[3]* and boot cs* base address, offset: 0x09c from pci_0 or cpu; 0x01c from pci_1 bits field name function initial value 31:0 various same as for pci_0 cs[3]* and boot cs* base address. 0x1f000000 GT-96100A advanced communication controller revision 1.0 193 table 188: pci_0 internal registers memory mapped base address, offset: 0x020 from pci_0 or cpu; 0x0a0 from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 2:1 type type read only. 0x0 3 prefetch prefetch read only. 0x0 11:4 reserved read only. 0x0 31:12 memmapbase defines the address assignment of the GT-96100A?s internal registers. reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x14000 table 189: pci_1 internal registers memory mapped base address, offset: 0x0a0 from pci_0 or cpu; 0x020 from pci_1 bits field name function initial value 31:0 various same as for pci_0 internal register?s memory mapped base address. 0x14000000 table 190: pci_0 internal registers i/o mapped base address, offset: 0x024 from pci_0 or cpu; 0x0a4 from pci_1 bits field name function initial value 0 memspace io space indicator 0x1 11:1 reserved read only. 0x0 31:12 iomapbase defines the address assignment of the GT-96100A?s internal registers. reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x14000 GT-96100A advanced communication controller 194 revision 1.0 table 191: pci_1 internal registers i/o mapped base address, offset: 0x0a4 from pci_0 or cpu; 0x024 from pci_1 bits field name function initial value 31:0 various same as for pci_0 internal register?s i/o mapped base address. 0x14000001 table 192: pci_0 subsystem device and vendor id, offset: 0x02c from pci_0 or cpu; 0x0ac from pci_1 bits field name function initial value 15:0 venid provides the subsystem vendor identifica- tion number. 0x0 31:16 devid provides the subsystem device identifica- tion number. 0x0 table 193: pci_1 subsystem device and vendor id, offset: 0x0ac from pci_0 or cpu; 0x02c from pci_1 bits field name function initial value 31:0 various same as for pci_0 subsystem device and vendor id. 0x0 table 194: expansion rom base address register, offset: 0x030 from pci_0 or cpu; 0x0b0 from pci_1 bits field name function initial value 0 erdecen expansion rom decode enable 0 - disable 1 - enable 0x0 11:1 reserved 0x0 31:12 erbase defines the address of the expansion rom memory space region assigned to the GT-96100A. this is where the expan- sion rom code appears in system mem- ory when bit 0 of this register contains a value of 1 and bit 1 of this device?s com- mand register contains a value of 1. this register is reserved in case expan- sion rom was not enabled at reset (dadr[5] sampled 0). 0x1f000 GT-96100A advanced communication controller revision 1.0 195 table 195: pci_0 capability list pointer register, offset: 0x034 from pci_0 or cpu, 0xb4 from pci_1 1 1. reserved if power management is disabled bits field name function initial value 7:0 capptr capability list pointer. read only. 0x40 31:8 reserved 0x0 table 196: pci_1 capability list pointer register, offset: 0x0b4 1 from pci_0 or cpu, 0x34 from pci_1 bits field name function initial value 7:0 capptr capability list pointer. read only. 0x40 31:8 reserved 0x0 table 197: pci_0 interrupt pin and line, offset: 0x03c from pci_0 or cpu; 0x0bc from pci_1 bits field name function initial value 7:0 intline provides interrupt line routing information. 0x0 15:8 intpin indicates which interrupt pin is used by the GT-96100A. note: the GT-96100A uses inta. 0x1 31:16 reserved read only. 0x0 table 198: pci_1 interrupt pin and line, offset: 0x0bc from pci_0 or cpu; 0x03c from pci_1 bits field name function initial value 31:0 various same as for pci_0 interrupt pin and line. 0x00000100 GT-96100A advanced communication controller 196 revision 1.0 table 199: pci_0 pmc register, offset: 0x040 from pci_0 or cpu, 0x0c0 from pci_1 1 1. reserved if power management is disabled bits field name function initial value 7:0 capid capability id read only from pci. 0x1 15:8 nullptr null pointer indicates that pmc is the last item in the capability list. read only from pci 0x0 18:16 pmcver pci power management spec revision read only from pci. 0x1 19 pmeclk pme clock read only from pci. 0x1 20 reserved read only from pci. 0x0 21 dsi device specific initialization read only from pci. 0x0 24:22 auxcur auxulary current requirements read only from pci. 0x0 25 d1sup d1 power management state support read only from pci 0x0 26 d2sup d2 power management state support read only from pci. 0x0 31:27 pmesup pme* signal support read only from pci. 0x0 table 200: pci_1 pmc register, offset: 0x0c0 from pci_0 or cpu, 0x040 from pci_1 1 bits field name function initial value 31:0 various same as for pci_0 pmc register. 0x00090001 GT-96100A advanced communication controller revision 1.0 197 table 201: pci_0 pmcsr register, offset: 0x044 from pci_0 or cpu, 0x0c4 from pci_1 1 bits field name function initial value 1:0 pstate power state 0x0 7:2 reserved read only from pci. 0x0 8 pme_en pme* pin assertion enable read only from pci. 0x0 12:9 dsel data select read only from pci. 0x0 14:13 dscale data scale read only from pci. 0x0 15 pme_stat pme* pin status read only from pci. 0x0 21:16 reserved read only from pci. 0x0 22 b2_b3 b2/b3 select read only from pci. 0x0 23 bpcc_en bus power/clock control enable read only from pci. 0x0 31:24 data state data read only from pci. 0x0 table 202: pci_1 pmcsr register, offset: 0x0c4 from pci_0 or cpu, 0x044 from pci_1 bits field name function initial value 31:0 various same as for pci_0 pmcsr register. 0x0 GT-96100A advanced communication controller 198 revision 1.0 7.14.3 function 1 configuration registers the GT-96100A acts as two function device. it?s pci slave interface responds to configuration transactions to function number 0 or 1. most of function 1 configuration registers are aliased to function 0 registers or reserved, except of the 3 swap bars. to access any of the swap base address registers, a configuration access addressed to function 1must be used with the appropriate offset. if an offset other than 0x010, 0x014, or 0x01c is accessed when specifying function 1, the transaction accesses the corresponding offset register in function 0. configura- tion transactions to any other function number are ignored. the GT-96100A acts as two function device regardless of multi-function bit (bit[7] in header type). however, this bit value after reset is 0. in a pc environment, in order for a bios to recognize the GT-96100A as a multi- function device (if swap bars are required in the system), set this bit and enable the swap bars (base address enable register) before bios starts. this can be done by programing by cpu software or by using the gt- 96100a?s auto-load option. table 203: function1 pci_0 swapped scs[1:0]* base address, offset: 0x110 from pci_0 or cpu; 0x190 from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 2:1 type type read only. 0x0 3 prefetch prefetch 0x1 11:4 reserved read only. 0x0 31:12 base defines the address assignment of swapped scs[1:0]*. reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x0 table 204: function 1 pci_1 swapped scs[1:0]* base address, offset: 0x190 from pci_0 or cpu; 0x110 from pci_1 bits field name function initial value 31:0 various same as for pci_0 swapped scs[1:0]* base address 0x08 table 205: function 1 pci_0 swapped scs[3:2]* base address, offset: 0x114 from pci_0 or cpu; 0x194 from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 GT-96100A advanced communication controller revision 1.0 199 2:1 type type read only. 0x0 3 prefetch prefetch 0x1 11:4 reserved read only. 0x0 31:12 base defines the address assignment of swapped scs[3:2]*. reserved if this bar is disabled through pci_0 base address registers? enable setting. 0x01000 table 206: function 1 pci_1 swapped scs[3:2]* base address, offset: 0x194 from pci_0 or cpu; 0x114 from pci_1 bits field name function initial value 31:0 various same as for pci_0 swapped scs[3:2]* base address. 0x01000008 table 207: function 1 pci_0 swapped cs[3]* & boot cs* base address, offset: 0x11c from pci_0 or cpu; 0x19c from pci_1 bits field name function initial value 0 memspace memory space indicator read only. 0x0 2:1 type type read only. 0x0 3 prefetch prefetch 0x0 11:4 reserved read only. 0x0 31:12 base defines the address assignment of cs[3]* and boot cs*, see table 144 . reserved if this bar is disabled through pci_0 base address registers? enable setting.) 0x1f000 table 205: function 1 pci_0 swapped scs[3:2]* base address, offset: 0x114 from pci_0 or cpu; 0x194 from pci_1 (continued) bits field name function initial value GT-96100A advanced communication controller 200 revision 1.0 table 208: function 1 pci_1 swapped cs[3]* & boot cs* base address, offset: 0x19c from pci_0 or cpu; 0x11c from pci_1 bits field name function initial value 31:0 various as in pci_0 swapped cs[3]* and boot cs* base address. 0x1f000000 GT-96100A advanced communication controller revision 1.0 201 8. i ntelligent i/o ( i 2 o ) s tandard s upport the GT-96100A includes hardware support for the intelligent i/o (i 2 o) standard. this support includes all of the registers required for implementing the i 2 o messaging unit as defined in the i 2 o specification. this messaging unit (mu) is compatible with that found in intel?s i960rx processors. however, the combination of mips processors and the GT-96100A delivers as much as 20 times the integer performance of the i960rp. the i 2 o hardware support found in the GT-96100A also provides designers of non-i 2 o embedded systems with important benefits. for example, the circular queue support in the mu provides a simple, powerful mechanism for passing queued messages between intelligent agents on a pci bus. even the simple message and doorbell reg- isters improve the efficiency of communication between agents on pci. note: even if you have no intention of using the entire i 2 o ?stack?, galileo technology recommends reading this entire section to learn about improving the application of the hardware to the design. 8.1 overview the best source for an overview description of i 2 o support is in the i 2 o specification documentation. the i 2 o specification defines a standard mechanism for passing messages between a host processor (a pen- tium ? , for example) and intelligent i/o processors (a networking card based on the GT-96100A and a mips pro- cessor, for example.) this same message passing mechanism is used to pass messages between peers in a system. i 2 o is defined to be bus independent but, in the real world, it runs over the pci. the basic process is quite simple: 1. a master wishing to post a message to a device, fetches a pointer from the device from a defined regis- ter in the target devices pci memory space (one of the i 2 o registers). 2. the master assembles the message in the targets memory space and then posts the fetched pointer into another register in the target device. posting the pointer generates an interrupt to the target?s processor. the i 2 o specification documentation also defines a simpler mechanism for implementing message passing through doorbell and message registers. the GT-96100A also includes this support. 8.2 i 2 o registers from the pci side, the registers used to implement i 2 o support resides in the first 128 bytes of the memory region defined by ras[1:0] base address register in pci function 0 of pci interface 0 1 . the i 2 o registers are accessible from the cpu side through an offset from the cpu internal space base register. note: index registers are not supported in GT-96100A. 1. there is no i 2 o support on the pci_1 interface. GT-96100A advanced communication controller 202 revision 1.0 table 209: i 2 o pci and cpu offsets i 2 o register pci side 1 cpu side 2 inbound message register 0 0x10 0x1c10 inbound message register 1 0x14 0x1c14 outbound message register 0 0x18 0x1c18 outbound message register 1 0x1c 0x1c1c inbound doorbell register 0x20 0x1c20 inbound interrupt cause register 0x24 0x1c24 inbound interrupt mask register 0x28 0x1c28 outbound doorbell register 0x2c 0x1c2c outbound interrupt cause register 0x30 0x1c30 outbound interrupt mask register 0x34 0x1c34 inbound queue port virtual register 0x40 0x1c40 outbound queue port virtual register 0x44 0x1c44 queue control register 0x50 0x1c50 queue base address register 0x54 0x1c54 inbound free head pointer register 0x60 0x1c60 inbound free tail pointer register 0x64 0x1c64 inbound post head pointer register 0x68 0x1c68 inbound post tail pointer register 0x6c 0x1c6c outbound free head pointer register 0x70 0x1c70 outbound free tail pointer register 0x74 0x1c74 outbound post head pointer register 0x78 0x1c78 outbound post tail pointer register 0x7c 0x1c7c reserved 0x80 to 4k - sdram ras[1:0] >4k - 1. offset from bar0 in pci memory space 2. offset from cpu internal space base register (location in mips cpu memory space) GT-96100A advanced communication controller revision 1.0 203 8.3 enabling i 2 o support the i 2 o registers are only visible from the pci side when i 2 o support is enabled via the pin strapping option shown in the reset configuration section. when i 2 o support is disabled, the locations from bar0+0x0 to bar0+0x7f appear as sdram. 8.4 register map compatibility with the i960rx family the GT-96100A?s register map is compatible with the i 2 o specification. however, some of the registers found in intel?s i960rx processors are not implemented. this information is shown in table 210 . 8.5 message registers the GT-96100A uses the message registers to send and receive short messages over the pci bus, without trans- ferring data into local memory. when written, message registers may cause an interrupt to be generated either to the mips cpu or to the pci bus. there are two types of message registers: ? inbound messages are sent by an external pci bus agent and received by the GT-96100A ? outbound messages are sent by the GT-96100A?s local cpu and received by an external pci agent the interrupt status for inbound messages is recorded in the inbound interrupt cause register. the interrupt status for outbound messages is recorded in the outbound interrupt cause register. 8.5.1 inbound messages there are two inbound message registers (imrs). when an imr is written from the pci side, a maskable interrupt request is generated in the inbound interrupt status register (iisr). if this request is unmasked, an interrupt request is issued to the mips cpu. the interrupt is cleared when the cpu writes a value of 1 to the inbound message interrupt bit in the iisr. the interrupt may be masked through the mask bits in the inbound interrupt mask register. table 210: register differences between the GT-96100A and i960rx register name GT-96100A i960rx comment apic register select not implemented implemented no apic support required for the gt- 96100a, not a part of the i 2 o spec. apic window select not implemented implemented no apic support required for the gt- 96100a, not a part of the i 2 o spec. index registers not implemented implemented index registers are not used for i 2 o mes- sage passing so this is not a compatibility issue. index registers are implemented as normal sdram in the GT-96100A. GT-96100A advanced communication controller 204 revision 1.0 8.5.2 outbound messages there are two outbound message registers (omrs). when an omr is written from the cpu side, a maskable interrupt request is generated in the outbound interrupt status register (oisr). if this request is unmasked, an interrupt request is issued to the pci_0 unit. the interrupt is cleared when an external pci agent writes a value of 1 to the outbound message interrupt bit in the oisr. the interrupt may be masked through the mask bits in the outbound interrupt mask register. 8.6 doorbell registers the GT-96100A uses the doorbell registers to request interrupts on the pci and cpu buses. there are two types of doorbell registers: ? inbound doorbells are set by an external pci bus agent to request interrupt service from the mips cpu ? outbound doorbells are set by the GT-96100A?s local cpu and to request an interrupt on pci 8.6.1 outbound doorbells the local mips processor generates an interrupt request to the pci bus by setting bits in the outbound doorbell register (odr). the interrupt may be masked in the oimr register, however masking the interrupt does not pre- vent the corresponding bit from being set in the odr. external pci agents clear the interrupt by setting bits in the odr to 1 through a write. 8.6.2 inbound doorbells the pci bus can generate an interrupt request to the local mips processor by setting bits in the inbound doorbell register (idr). the interrupt may be masked in the iimr register, however masking the interrupt does not pre- vent the corresponding bit from being set in the idr. the cpu clears the interrupt by setting bits in the idr (writing a 1). 8.7 circular queues the circular queues form the heart of the i 2 o message passing mechanism, and are also the most powerful part of the mu built into the GT-96100A. there are four circular queues in the mu: two inbound and two outbound. 8.7.1 inbound message queues there are two inbound message queues: ? the inbound posts queue is for messages from other pci agents for the mips cpu to process ? the inbound free queue is for messages from mips cpu to pci agent in response to an incoming mes- sage. GT-96100A advanced communication controller revision 1.0 205 the two inbound queues allow external pci agents to post inbound messages for the local mips cpu in one queue and receive free messages (no longer in use) returning from the mips cpu. the process is as follows: 1. an external pci agent posts an inbound message. 2. the mips cpu receives and processes the message. 3. when the processing is complete, the mips cpu places the message back into the inbound free queue so that it may be reused. 8.7.2 outbound message queues there are two outbound message queues: ? the outbound post queue is for messages from the mips cpu to other pci agents to process. ? the outbound free queue is for messages are from pci agent to the mips cpu in response to an outgo- ing message. the two outbound queues allow the mips cpu to post outbound messages for external pci agents in one queue and receive free messages (no longer in use) returning from external pci agents. the process is as follows: 1. the mips cpu posts an outbound message. 2. the external pci agent receives and processes the message. 3. when the processing is complete, the external pci agent places the message back into the outbound free queue so that it may be reused. 8.7.3 memory for circular queues data storage for the circular queues must be allocated in local sdram. the base address for the queues is set in the queue base address register (qbar). each queue entry is a 32-bit data value. the circular queue sizes range from 4k entries (16kbytes) to 64k entries (256kbytes) yielding a total local memory allotment of 64kbytes to 1mbyte. all four queues must be the same size and be contiguous in the memory space. queue size is set in the queue control register. the starting address of each queue is based on the qbar address and the size of the queues as shown in the table below. table 211: circular queue starting addresses queue starting address inbound free qbar inbound post qbar + queue size outbound post qbar + 2*queue size outbound free qbar + 3*queue size GT-96100A advanced communication controller 206 revision 1.0 each queue has a head pointer and a tail pointer kept in the GT-96100A?s internal registers. these pointers are offsets from the qbar. writes to a queue occur at the head of the queue; reads occur from the tail. the head and tail pointers are incremented by either the cpu software or messaging unit hardware. the pointers wrap around to the first address of a queue when they reach queue size. pci read/write from queue is always single-word. an attempt to burst from an i 2 o queue will result in disconnect after 1st data transfer. figure 31: i 2 o circular queue operation outbound free queue outbound queue port to pci pci write outbound post queue pci read inbound post queue inbound free queue pci i/f inbound queue port to pci pci write pci read pci i/f outbound free head pointer (0x70) outbound free tail pointer (0x74) outbound post head pointer (0x78) outbound post tail pointer (0x7c) inbound post head pointer (0x68) inbound post tail pointer (0x6c) inbound free head pointer (0x60) inbound free tail pointer (0x64) incremented by GT-96100A incremented by local s/w incremented by GT-96100A incremented by local s/w incremented by GT-96100A incremented by local s/w incremented by GT-96100A incremented by local s/w mips cpu fetches a free outbound queue message here, then increments the tail pointer. mips cpu posts an outbound message here, then increments the head pointer. mips cpu fetches inbound message here, then increments the tail pointer. mips cpu writes free inbound message here, then increments the head pointer. GT-96100A advanced communication controller revision 1.0 207 8.7.4 inbound/outbound queue port register function the circular queues are accessed by external pci agents through the inbound and outbound queue port virtual registers in the i 2 o/pci address space, decoded by bar0. note: the inbound and outbound queue port virtual registers are not read/write physical registers within the GT-96100A. these virtual registers are reading and writing pointers into the circular queues (located in sdram) that are controlled by the GT-96100A. refer to figure 31 . 8.7.4.1 inbound queue port reads and writes when inbound queue port (iqp) is written from pci, the written data is placed on the inbound post queue. the iqp is posting the message to the local cpu. an interrupt is generated to the mips cpu when the inbound post queue is written to alert the cpu that a message needs processing. when this register is read from the pci side, it is returning a free message from the tail of inbound free queue. 8.7.4.2 the outbound queue port the outbound queue port (oqp) returns data from the tail of the outbound post queue when read from the pci side. the oqp is returning the next message requiring service by the external pci agent. when this register is written from pci, the data for the write is placed on the outbound free queue. this, in turn, returns a free mes- sage for reuse by the local mips cpu. 8.7.5 inbound post queue the inbound post queue holds posted messages from external pci agents to the mips cpu. the mips cpu fetches the next message process from the queue tail. external agents post new messages to the queue head. the tail pointer is maintained in software by the mips cpu. the head pointer is maintained automatically by the gt- 96100a upon posting of a new inbound message. pci writes to the iqp are passed to local memory location at qbar + inbound post head pointer. after this write completes, the GT-96100A increments the inbound post head pointer by 4 bytes (1 word); it now points to the next available slot for a new inbound message. an interrupt is also sent to the mips cpu to indicate the pres- ence of a new message pointer. from the time the pci write ends till the data is actually written to dram, any new write to inbound port will result in retry. if queue is full, a new pci write to the queue will result in retry. inbound messages are fetched by the mips cpu by reading the contents of the address pointed to by the inbound post tail pointer. it is the cpus responsibility to increment the tail pointer to point to the next unread message. 8.7.6 inbound free queue the inbound free queue holds available inbound free messages for external pci agents to use. the mips cpu places free messages at the queue head; external agents fetch free messages from the queue tail. the head pointer is maintained in software by the mips cpu. the tail pointer is maintained automatically by the GT-96100A upon a pci agent fetching a new inbound free message (except when there is an error, see below.) GT-96100A advanced communication controller 208 revision 1.0 pci reads from the inbound queue port return data to the local memory location at qbar + inbound free tail pointer according to the following conditions: ? if the inbound free queue is not empty (as indicated by head pointer not equal to tail pointer), then the data pointed to by qbar + inbound free tail pointer is returned. ? if the queue is empty (head pointer equals tail pointer), the value 0xffff.ffff is returned. this indi- cates there are no inbound message slots available (an error condition.) the mips processor places free message buffers in the inbound free queue by writing the pointer to the location pointed to by the head pointer. it is the processor?s responsibility to then increment the head pointer. 8.7.7 outbound post queue the outbound post queue holds outbound posted messages from the mips cpu to external pci agents. the mips cpu places outbound messages at the queue head; external agents fetch the posted messages from the queue tail. the outbound post tail pointer is automatically incremented by the GT-96100A. the head pointer must be incremented by the local mips cpu. pci reads from the outbound queue port return the data pointed to by qbar + outbound post tail pointer (the next posted message in the outbound queue.) the following conditions apply: ? if the outbound post queue is not empty (the head and tail pointers are not equal), the data is returned as usual and the GT-96100A increments the outbound post tail pointer ? if the outbound post queue is empty (the head and tail pointers are equal), the value 0xffff.ffff is returned as long as the outbound post head and tail pointers are not equal, a pci interrupt is requested. this is done to indicate the need to have the external pci agent read the outbound post queue. when the head and tail pointers are equal, no pci interrupt is generated since no service is required on the part of the external pci agent (or pci system host in the case of a pc server.) in either case, the interrupt can be masked in the oimr register. the mips cpu places outbound messages in the outbound post queue by writing to the local memory location pointed to by the outbound post head pointer. after writing this pointer, it is the cpu?s responsibility to incre- ment the head pointer. 8.7.8 outbound free queue the outbound free queue holds available outbound message buffers for the local mips processor to use. exter- nal pci agents place free message at the queue head; the mips cpu fetches free message pointers from the queue tail. the tail pointer in maintained in software by the mips cpu. the head pointer is maintained automat- ically by the GT-96100A upon a pci agent posting a new (?returned?) outbound free message. pci writes to the outbound queue port result in the data being written to the local memory location at qbar + outbound free head pointer. after the write completes, the GT-96100A increments the head pointer. from the time the pci write ends till the data is actually written to dram, any new write to outbound port will result in retry. if the head pointer and tail pointer become equal (an indication that the queue is full), an inter- rupt is sent to the mips cpu. if queue is full, a new pci write to the queue will result in retry. GT-96100A advanced communication controller revision 1.0 209 the mips processor obtains free outbound message buffers from the outbound free queue by reading data from the location pointed to by the tail pointer. it is the processor?s responsibility to then increment the tail pointer. 8.8 i 2 o support registers if i 2 o is enabled (i.e., dadr[8] was sampled ?0? at reset) its related registers are accessible from the cpu side and the pci_0 side. to access registers from the pci_0 side, the address must be in the first 4kbytes of pci_0 scs[1:0]* base register space. to access from cpu side, the address must be in the 4kbytes of cpu internal space base register space. pci_1 has no access to i 2 o registers. if pci_1 address hits first 4kbytes of pci_1 scs[1:0]* bar space, it accesses sdram. if accessed from the pci_0 side, address offset is with respect to the pci_0 scs[1:0]* base address register contents. if accessed from the cpu side, address offset is with respect to the cpu internal space base register + 0x1c00. table 212: i 2 o circular queue functional summary queue name pci port generate pci interrupt? generate cpu interrupt? head pointer maintaine d by... tail pointer maintained by... inbound post inbound queue port no yes, when queue is written GT-96100A mips cpu inbound free no no mips cpu GT-96100A outbound post outbound queue port yes, when queue is not empty no mips cpu GT-96100A outbound free no yes, when queue is full GT-96100A mips cpu GT-96100A advanced communication controller 210 revision 1.0 note: i 2 o registers can be accessed from the cpu and pci_0 sides (unless stated otherwise). if accessed from the pci_0 side, address offset is with respect to the pci_0 scs[1:0]* base address register contents. if accessed from cpu side, the address offset is with respect to the cpu internal space base register + 0x1c00. table 213: i 2 o support register map description offset page number inbound message register 0 0x10 page 211 inbound message register 1 0x14 page 211 outbound message register 0 0x18 page 211 outbound message register 1 0x1c page 211 inbound doorbell register 0x20 page 212 inbound interrupt cause register 0x24 page 212 inbound interrupt mask register 0x28 page 213 outbound doorbell register 0x2c page 213 outbound interrupt cause register 0x30 page 214 outbound interrupt mask register 0x34 page 214 inbound queue port virtual register 0x40 page 215 outbound queue port virtual register 0x44 page 215 queue control register 0x50 page 215 queue base address register 0x54 page 216 inbound free head pointer register 0x60 page 216 inbound free tail pointer register 0x64 page 216 inbound post head pointer register 0x68 page 216 inbound post tail pointer register 0x6c page 217 outbound free head pointer register 0x70 page 217 outbound free tail pointer register 0x74 page 217 outbound post head pointer register 0x78 page 218 outbound post tail pointer register 0x7c page 218 GT-96100A advanced communication controller revision 1.0 211 table 214: inbound message register 0, offset: 0x10 bits field name function initial value 31:0 inmsg0 inbound message register_0 read only from the cpu. when written, a bit is set in the inbound interrupt cause register and an interrupt is generated to the cpu (if unmasked). first register of two intended for messages from pci to cpu. 0x0 table 215: inbound message register 1, offset: 0x14 bits field name function initial value 31:0 inmsg1 inbound message register_1 read only from the cpu. when written, a bit is set in the inbound interrupt cause register and an interrupt is generated to the cpu (if unmasked). second register of two intended for mes- sages from pci to cpu. 0x0 table 216: outbound message register 0, offset: 0x18 bits field name function initial value 31:0 outmsg0 outbound message register_0 read only from the pci. when written, a bit is set in the outbound interrupt cause register and an interrupt is generated to the pci (if unmasked). first register of two intended for messages from cpu to pci. 0x0 table 217: outbound message register 1, offset: 0x1c bits field name function initial value 31:0 outmsg1 outbound message register_1 read only from the pci. when written, a bit is set in the outbound interrupt cause register and an interrupt is generated to the pci (if unmasked). second register of two intended for mes- sages from cpui to pci. 0x0 GT-96100A advanced communication controller 212 revision 1.0 table 218: inbound doorbell register, offset: 0x20 bits field name function initial value 31:0 indoor inbound doorbell register if not masked by inbound interrupt mask register, setting a bit in this register to 1 by the pci causes a cpu interrupt. writing 1 to the bit by the cpu clears the bit (and de-assert the interrupt). 0x0 table 219: inbound interrupt cause register, offset: 0x24 bits field name function initial value 0 inmsg0int inbound message_0 interrupt this bit is set when inbound message 0 register is written. the cpu writes it with 1 to clear it. 1 1. unlike intel?s i960rp, bits [8:6] and bit 3 are reserved since the GT-96100A does not support index, apic, or nmi mechanisms. 0x0 1 inmsg1int inbound message_1 interrupt this bit is set when inbound message_1 register is written. cpu writes it with 1 to clear it. 2 2. an interrupt to cpu is generated if any of the bits 0,1,2,4, or 5 is set to 1 given that its corresponding entry in the inbound interrupt mask register is not set. 0x0 2 indoorint inbound doorbell interrupt this bit is set when at least one bit of inbound doorbell register is set. this bit is read only. 0x0 3reserved 0x0 4 inpqint inbound post queue interrupt this bit is set when the inbound post queue gets written. the cpu writes it with 1 to clear it. 0x0 5 outfqovr outbound free queue overflow interrupt this bit is set when the outbound free queue is full. the cpu writes it with 1 to clear it. 0x0 31:6 reserved 0x0 GT-96100A advanced communication controller revision 1.0 213 table 220: inbound interrupt mask register, offset: 0x28 bits field name function initial value 0 inmsg0intmsk inbound message_0 interrupt mask 0x0 1 inmsg1intmsk inbound message_1 interrupt mask 0x0 2 indoorintmsk inbound doorbell interrupt mask 0x0 3reserved 0x0 4 inpqintmsk inbound post queue interrupt mask 0x0 5 outfqovrmsk outbound free queue overflow interrupt mask when set, no interrupt to cpu is gener- ated for set outfqovr bit in inbound inter- rupt cause register. 0x0 31:6 reserved 0x0 table 221: outbound doorbell register, offset: 0x2c bits field name function initial value 31:0 outdoor outbound doorbell register setting a bit in this register to 1 by the cpu causes a pci interrupt if not masked by the outbound interrupt mask register. 1 writing 1 to the bit by the pci clears the bit (and de-assert the interrupt). 1. unlike intel?s i960rp, there are no reserved bits for pci interrupts inta#, intb#, intc#, intd#. 0x0 GT-96100A advanced communication controller 214 revision 1.0 table 222: outbound interrupt cause register, offset: 0x30 bits field name function initial value 0 outmsg0int outbound message_0 interrupt this bit is set when outbound message_0 register is written. the pci writes it with 1 to clear it. for the cpu, this bit is read only. 0x0 1 outmsg1int outbound message_1 interrupt this bit is set when outbound message_1 register is written. pci writes it with 1 to clear it. for the cpu, this bit is read only. 1 1. an interrupt to pci is generated if any of the bits 0,1,2, or 3 is set to 1 given that its corresponding entry in the out- bound interrupt mask register is not set. 0x0 2 outdoorint outbound doorbell interrupt: this bit is set when at least one bit of out- bound doorbell register is set. this bit is read only. 0x0 3 outpqint outbound post queue interrupt this bit is set as long as outbound post queue is not empty. this bit is read only. 0x0 31:4 reserved 0x0 table 223: outbound interrupt mask register, offset: 0x34 bits field name function initial value 0 outmsg0intmsk outbound message_0 interrupt mask. 0x0 1 outmsg1intmsk outbound message_1 interrupt mask. 0x0 2 outdoorintmsk outbound doorbell interrupt mask 0x0 3 outpqintmsk outbound post queue interrupt mask: when set, no interrupt to pci is generated for set outpqint bit in the outbound inter- rupt cause register. 0x0 31:4 reserved 0x0 GT-96100A advanced communication controller revision 1.0 215 table 224: inbound queue port virtual register, offset: 0x40 bits field name function initial value 31:0 inqpvreg inbound queue port virtual register a pci write to this port results in a write to the inbound post queue. a read from this port results in a read from the inbound free queue. reserved from the cpu side. 0x0 table 225: outbound queue port virtual register, offset: 0x44 bits field name function initial value 31:0 outqpvreg outbound queue port virtual register a pci write to this port results in a write to the outbound free queue. a read from this port results in a read from the outbound post queue. reserved from the cpu side. 0x0 table 226: queue control register, offset: 0x50 bits field name function initial value 0 cirqen circular queue enable if 0, a pci write to this queue is ignored; upon a pci read from queue 0xffffffff is returned. reserved from the pci side. 0x0 5:1 cirqsize circular queue size 00001 - 16 kbytes 00010 - 32 kbytes 00100 - 64 kbytes 01000 - 128 kbytes 10000 - 256 kbytes reserved from pci side. 0x1 31:6 reserved 0x0 GT-96100A advanced communication controller 216 revision 1.0 table 227: queue base address register, offset: 0x54 bits field name function initial value 19:0 reserved 0x0 31:20 qbar queue base address register reserved from the pci side. 0x0 table 228: inbound free head pointer register, offset: 0x60 bits field name function initial value 1:0 reserved 0x0 19:2 infhptr inbound free head pointer 1 reserved from the pci side. 1. this register is maintained by cpu software. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 table 229: inbound free tail pointer register, offset: 0x64 bits field name function initial value 1:0 reserved 0x0 19:2 inftptr inbound free tail pointer 1 reserved from the pci side. 1. this register is incremented by the GT-96100A after a pci read from inbound port. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 table 230: inbound post head pointer register, offset: 0x68 bits field name function initial value 1:0 reserved 0x0 19:2 inphptr inbound post head pointer 1 reserved from the pci side. 1. this register is incremented by the GT-96100A after a pci write to inbound port. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 GT-96100A advanced communication controller revision 1.0 217 table 231: inbound post tail pointer register, offset: 0x6c bits field name function initial value 1:0 reserved 0x0 19:2 inptptr inbound post tail pointer 1 reserved from the pci side. 1. this register is maintained by the cpu software. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 table 232: outbound free head pointer register, offset: 0x70 bits field name function initial value 1:0 reserved 0x0 19:2 outfhptr outbound free head pointer 1 reserved from the pci side. 1. this register is incremented by the GT-96100A after pci write to outbound port. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 table 233: outbound free tail pointer register, offset: 0x74 bits field name function initial value 1:0 reserved 0x0 19:2 outftptr outbound free tail pointer 1 reserved from the pci side. 1. this register is maintained by cpu software. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 GT-96100A advanced communication controller 218 revision 1.0 table 234: outbound post head pointer register, offset: 0x78 bits field name function initial value 1:0 reserved 0x0 19:2 outphptr outbound post head pointer 1 reserved from the pci side. 1. this register is maintained by the cpu software. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 table 235: outbound post tail pointer register, offset: 0x7c bits field name function initial value 1:0 reserved 0x0 19:2 outptptr outbound post tail pointer 1 reserved from the pci side. 1. this register is incremented by the GT-96100A after a pci read from the outbound port. it is reserved for pci accesses. 0x0 31:20 qbar queue base address register read only. 0x0 GT-96100A advanced communication controller revision 1.0 219 9. i ndependent dma c ontrollers (idma c ontrollers ) the GT-96100A has four independent dma controllers. the idma controllers are used to optimize system per- formance by moving large amounts of data without significant cpu intervention. rather than having the cpu read data from one source and write it to another, use the idma controllers to directly transfer data independent of the cpu. this allows the cpu to continue executing other instructions simultaneous to the movement of data. it is possible for each idma controller to move data between peripherals on the sdram/device controller bus, between devices on the pci buses, or between peripherals on the sdram/device controller bus and devices on the pci buses. each idma transfer uses one of two internal 64-byte fifos for moving data. data is transferred from the source device into an internal fifo, and from the internal fifo to the destination device. the idma controller can be programmed to move up to 64kbytes of data per transaction. the burst length of each transfer of each idma can be set from 1 to 64 bytes. accesses can be non-aligned both in the source and the destination. the GT-96100A has two ?72-byte? fifos available for the utilization by the dma engines. although the maxi- mum dma burst size is 64 bytes, the extra eight bytes in the fifo are required for non-double word aligned transfers. two fifos allow for concurrency between two dma transactions. this means one dma channel can be reading data from the sdram into the first fifo while another channel is writing data to a pci target from the second fifo. the dma channels support chained mode of operation. the descriptors are stored in memory, and the dma engine moves the data until the null pointer is reached. fly-by dma transfers are also supported. this type of dma transfers greatly increase memory bandwidth. fly- by transfers are permitted to and from a device or to and from sdram. the dma can be initiated by the cpu writing a register, an external request via a dmareq* pin, or from a timer/counter. in cases where the transfer needs to be externally terminated, an end of transfer (eot[3:0]) pin must be asserted (driven low) for the corresponding dma channel. 9.1 dma channel registers each dma channel record consists of the following registers. these registers can be written by the cpu, pci, or idma controller in the process of fetching a new record from memory. 9.1.1 byte count register the byte count register consists of four registers at offsets 0x800 - 0x80c. this register is programmed with a 16-bit number containing the number of data bytes this channel must dma. the maximum number of bytes the dma controller can be configured to transfer is 64k-1. this register decre- ments at the end of every burst of transmitted data from source to destination. when the byte count register is 0, or the end of transfer pin is asserted, the dma transaction is finished or ter- minated. GT-96100A advanced communication controller 220 revision 1.0 9.1.2 source address register the source address register is at offset 0x810 - 0x81c. this register is programmed with a 32-bit address. this is the source address for data and can be from the sdram/device controller or from pci. this register either increments, decrements, or holds the same value according to bits [3:2] of the channel con- trol register, see table 236 . 9.1.3 destination address register the destination address register is at offset 0x820 - 0x82c. this register is programmed with a 32-bit address. this is the destination address for data. it can be programmed to the sdram/device or to pci. this register either increments, decrements, or holds the same value according to bits [5:4] of the channel con- trol register, see table 236 . 9.1.4 pointer to the next record register the pointer to the next record register is at offset 0x830 - 0x83c. the register contains a 32-bit address where the values for the next dma channel record can be loaded for chained operation. this can be from the sdram/device controller or from pci. the byte count, source address, and destination address must be located at sequential addresses. note: the next record pointer must be 16 bytes aligned. this means bits [3:0] must be set to 0. a value of 0 (null) for this register indicates that this is the last record in the chain.this register is only used when the channel is configured for chained mode, see table 236 . 9.1.5 channel registers the channel register is at offset 0x840 - 0x84c. this register controls the dma operation modes. a detailed description of this register?s bits is in table 9.2 . GT-96100A advanced communication controller revision 1.0 221 9.2 dma channel control register (0x840 - 0x84c) each dma channel has its own unique control register where certain dma modes can be programmed. table 236 provides the bit descriptions for each field in the control register and describes the functionality of the dma control register in certain modes. see table 264 for further information. table 236: dma channel control register (0x840 - 0x84c) function description flybyen bit flybyen determines whether or not a dma transfer uses an internal dma fifo to host the data from the source, prior to transferring it to the destination. the sdram address must always be programmed in the source address register when performing a fly-by dma whether the dma source or destination is the sdram. r/w bit this bit is meaningful only in fly-by mode, flybyen bit set to 1. r/w indicates whether the dma transaction with the sdram is a read or write. srcdir, bits[3:2] the srcdir field contains information about how the source address for the dma transfer is handled. destdir, bits[5:4] the destdir field contains information about how the destination address for the dma transfer is handled. dattranslim, bits[8:6] the dattranslim field contains the burst limit of each data transfer. the burst limit can vary from one to 64 bytes in module-2 steps (i.e. 1, 2, 4, 8,..., 64). chainmod, bit 9 chainmod determines whether this channel is set in chained mode or not. in chained mode, the channel record?s parameters for the current transac- tion (byte count, source, destination, and next record pointer) must be initialized in sdram/device memory space or pci devices. the address of the first record must be initialized by writing it to the channel?s next record pointer register. in non-chained mode the byte count, source, and destination registers must be initialized prior to enabling the channel. intmode, bit 10 intmode controls when this channel asserts the dmacomp (dma complete) inter- rupt. if chained mode is disabled, the setting of intmode is irrelevant and dmacomp interrupt will be asserted every time the byte count reaches 0. transmod, bit 11 transmod indicates whether the channel is set to operate in demand mode or block mode. chanen, bit 12 chanen enables or disables the dma channel. the dma channel is enabled or disabled via chanen if the channel is in demand or block mode. fetnexrec, bit 13 fetnexrec is a field which is significant only when chained mode is enabled for the channel. GT-96100A advanced communication controller 222 revision 1.0 dmaactst, bit 14 (read only) dmaactst is a read only field that can be polled to see the dma activity status of the channel. in non-chain mode, this bit is de-asserted when byte_count reaches zero. in chain-mode, this bit is de-asserted when the pointer to next record is null and byte_count reaches zero. this bit is reset if the cpu sets chanen to 0 during dma transfer. sda, source/destina- tion alignment, bit 15 the sda bit determines whether address alignment is done for source or destina- tion. when a device such as a fifo is the destination of a dma, it is recommended to use destination alignment to avoid destructive writes. likewise, if a device such as a fifo is the source of a dma, it is recommended to use source alignment to avoid destructive reads. if both the dma source and destination addresses are aligned, the meaning of this bit is irrelevant. mask dma requests, mdreq, bit 16 some slower devices require extra time in order to de-assert a dma request sig- nal. this bit can be used to provide this extra time. close descriptor enable, cde, bit 17 a dma transfer may be halted (by an eot signal or fetchnextrec is asserted) with some data remaining in the buffer pointed at by the current descriptor. this bit allows writing the remaining byte count in bits 31:16 of the byte_count field of the descriptor (located in memory). by writing this field, ownership of the descriptor is returned to the cpu. the cpu then calculates the total number of bytes transferred by the dma channel by sub- tracting the remaining byte count from the original byte_count. end of transfer enable, eote, bit 18 this bit provides devices which have access to a dma engine to stop a dma trans- fer prior to its completion. in chain mode, this causes fetching a new descriptor from memory (if pointer to next record is not equal to null) and executing the next dma. if the dma channel is in non-chain mode, then the current dma transfer is stopped without further action. end of transfer inter- rupt enable, eote, bit 19 eotie enables or disables interrupts due to end of transfer (eot) signal activa- tion. abort dma, abr, bit 20 it is possible that the cpu may need to abort a dma transfer and reprogram the dma. this bit flushes internal indications which would normally not get flushed by a mere channel disable. the abr bit must be used together with en/dis if cde and/or eot are enabled and the cpu requires to abort a transfer for reprogramming. slp (bits [22:21]), dlp (bits [24:23]), rlp (bits [26:25]) slp, dlp, and rlp bits are used to redefine address space of source, destination, or record address location. these enable overriding the local address space with pcimem0 or pcimem1address space. table 236: dma channel control register (0x840 - 0x84c) (continued) function description GT-96100A advanced communication controller revision 1.0 223 table 237: location of source address, slp slp ([22:21]) function 00 source address is in local address space. 01 source address is in pci_0 memory space. 10 source address is in pci_1 memory space. 11 reserved. table 238: location of destination address, dlp dlp ([24:23]) function 00 destination address is in local address space. 01 destination address is in pci_0 memory space. 10 destination address is in pci_1 memory space. 11 reserved. table 239: location of record address, rlp rlp ([26:25]) function 00 record address is in local address space. 01 record address is in pci_0 memory space. 10 record address is in pci_1 memory space. 11 reserved. GT-96100A advanced communication controller 224 revision 1.0 figure 32: chained mode dma 9.3 restarting a disabled channel in non-chained mode, chanen must be set to 1. in chained mode, the software must find out if the first fetch took place. if it did, only chanen is set to 1. if it did not, the fetnexrec is also be set to 1. 9.4 reprogramming an active channel to reprogram an active channel, the channel must first be disabled by setting chanen to 0. if cde and/or eote are set, then abr must also be set. then it must be assured that the channel is no longer active (for example by polling the dmaactst of the channel). new dma parameters must be programmed prior to re-enabling the channel via setting chanen to 1. gt-64010 channel 0 dma registers byte count (bytect) source address (srcadd) destination address (destaddr) next record pointer (nextrecptr): 0x10 bytect srcadd destaddr nextrecptr: 0x100 0x10 0x14 0x18 0x1c x x x x 0x100 0x104 0x108 0x10c transfer #1 transfer #2 transfer #n bytect srcadd destaddr nextrecptr: y bytect srcadd destaddr null pointer: 0x0 GT-96100A GT-96100A advanced communication controller revision 1.0 225 9.5 arbitration the dma controller has a programmable arbitration scheme between its four channels. the channels are grouped into two groups: ? one group includes channel 0 and 1 ? the other group includes channels 2 and 3. the channels in each group are programmed to have priority so that a selected channel has the higher priority or the same priority in round robin. the priority between the two groups is programmed in a similar way so that a selected group has a higher priority or to have the same priority in round robin. the priority scheme has additional flexibility with the programmable priority option. with the priority option, the dma bandwidth allocation is divided in a fairer way. the dma arbiter control register can be reprogrammed any time regardless of the channels? status (active or not active). 9.6 current descriptor pointer registers each dma channel has a current descriptor pointer register (cdptr) associated with it. they are located at off- sets 0x870-0x7c. these descriptor pointers are read/write registers, however, the cpu should not write them. when the nptr (next pointer) is written by the cpu, then the cdptr reloads itself with the same value written to nptr. after processing a descriptor, the dma channel updates the current descriptor using cdptr, saves nptr into cdptr, and fetches a new descriptor. this register is used for closing the current descriptor before fetching the next descriptor. 9.7 design information the following sections contain more detailed information about the GT-96100A?s idma controllers. the follow- ing definitions are used throughout this section: table 240: idma controller design information terms and definitions term definition device a device located on the memory bus mapped to one of the GT-96100A?s chip selects (including bootcs). pci agent any device located on the pci bus. sdram sdram memory located on the memory bus. GT-96100A advanced communication controller 226 revision 1.0 9.7.1 dma in demand mode demand mode is especially designed for transferring data between memory (device, sdram, pci agent) and a device. this is because the dmaack* is asserted only when the GT-96100A is accessing a device. in this mode, the transfer initiator (usually a device) asserts dmareq* to signal the GT-96100A that a new dma transfer should begin. as an acknowledgment response, the GT-96100A asserts the dmaack* to signal that the asserted dmareq* is currently being processed. in each dma transfer, the dma attempts to read the amount of dattranlim bytes from the source address and writes it to destination address. in the source direction, at the beginning and end of the dma, there may be less than dattranlim bytes if the address is not aligned or the remaining byte count to be transferred is smaller then the dattranlim. in the destination direction, the dma writes all data that was read from the source to the desti- nation. this may happen in two dma accesses if the destination address is not aligned. the channel stays active until the byte count reaches the terminal count or until the cpu disables the channel. note: if the dmareq* is always asserted, then this is equivalent to transfer data in block mode. 9.7.1.1 asserting and deasserting dmareq* the dmareq* must be asserted as long as the transfer initiator has at least dattranlim of bytes to provide (in case that it is the source) or as long as it has space to absorb at least dattranlim of bytes (in case that it is the destination). the dmareq* should be deasserted by the source when the transfer initiator sees that it does not have at least dattranlim of bytes to provide (i.e. fifo empty). dmareq* should also be deasserted by the destination when it does not have enough space to absorb at least dattranlim of bytes (i.e. fifo full) and dmaack* is asserted low. 9.7.1.2 asserting dmaack* the dmaack* is asserted only when the GT-96100A accesses a device. it is asserted when ale is asserted. 9.7.1.3 dmareq* sampling the dmareq* is sampled all the time but it influences arbitration only in the dma arbitration cycle or when all channels are idling. the dma arbitration cycle is the cycle in which the destination unit inside the GT-96100A acknowledges the last written data from the dma unit. GT-96100A advanced communication controller revision 1.0 227 9.7.1.4 transferring data examples/recommendations 9.7.1.5 dma in block mode in block mode, no hand shake signals are used to initiate dma transfers. the dma unit completes the transfer once the cpu has programmed the dma and enabled it. 9.7.2 non-chain mode in non-chain mode, the cpu or pci master initiates the dma channel parameters (source, destination byte count and command registers).the dma starts to transfer data after the enable bit in the command register is set to 1. the dma remains in an active state until the byte count reaches a terminal count or until the channel is disabled. table 241: source and data transfer examples source destination description sdram/pci sdram/pci in this case it is better to use blockmode cause memory is typi- cally ready all the time and dmaack* is not asserted. if you choose to work in demand mode, dmaack* should be externally generated (i.e., polling accesses of the GT-96100A to certain addresses). device sdram or pci the device transfer initiator asserts a dmareq* when it has at least dattranlim number of bytes to give. it must de-assert the dmareq* when no more data is ready and dmaack* is asserted. even if another master drives the dmareq*, the dmaack* can signal to that master that the GT-96100A is currently accessing the device for read. sdram or pci device the device transfer initiator asserts a dmareq* when it has enough room for dattranlim number of bytes to be written to it and dmaack* is asserted. even if another master drives the dmareq*, the dmaack* can signal the master that the gt- 96100a is currently accessing the device for write. note: in this situation, the GT-96100A asserts the dmaack* when its accessing the device for write. this is problem- atic if dattranlimit is smaller than or equals eight bytes. the dmaack* is seen outside late, and due to this the de-assertion of the dmareq*, is not seen in the dma arbitration cycle. although the device does not want to be accessed, a new transfer may begin. ? if dattranlimit is bigger then eight bytes there is no problem. in this case, it is recommended to have a device that can accepts bursts. ? a solution when using one channel only and dattran- lim is less or equal to eight bytes is to set the mdreq bit. GT-96100A advanced communication controller 228 revision 1.0 9.7.3 chain mode in chain mode, the dma channel parameters (source, destination byte count and pointer to next record) are read from records located in memory, device, or pci. the dma channel stays in the active state until pointer to next record is null and the byte count reaches the terminal count. in this mode, an interrupt can be asserted every time the byte count reaches the terminal count or when both the byte count reaches the terminal count and the pointer to next record is null. 9.7.4 dynamic dma chaining dynamic chaining is when dma records are added to a chain that an idma controller is actively working on. the main issue is to synchronize between when the GT-96100A reads the last chain record (the null pointer) to the time the cpu changes the current last dma record. following is an algorithm which provides this synchroni- zation mechanism. 1. prepare the new record. 2. change the last record's pointer to next record to point to the new record. 3. read the dma control register. if the dmaactst bit is 0 (not active) { update the pointer to next record in the GT-96100A assert the fetnexrec bit } else { read the pointer to next record the GT-96100A. if it's equal to null { mark (by using a flag) that in the next dma chain complete interrupt you'll need to { update the nrp register in the gt-64010 write the fetch next record } } } 9.7.5 fly-by dma fly-by is a way to move data directly from the source of the data to its destination. while the source drives the data onto the data bus, the destination immediately latches it into its buffers/memory. the data does not pass through the GT-96100A. this saves at least half of the ad bus bandwidth. fly-by cycles are requested by the dma channel and controlled by the memory unit. 9.7.5.1 flyby in the GT-96100A during fly-by, the GT-96100A supplies the full information to the sdram involved in the transaction. this includes all control signals (sras*, scas*, swr*, scs* and sdqm) and the address lines (dadr, ba0, ba1). for the device, it supplies the control signals (cstiming*, dmaack* and devrdwr*) that support the same waveforms as if the device were not working in fly-by mode. this means that the dmaack* and devrdwr* are GT-96100A advanced communication controller revision 1.0 229 latched using ale. the external logic will have to form the address to the device (if needed) and correct write signals to the device if the device is the destination. the fly-by cycle is totally compliant with the sdram waveforms and the device has to keep up with its speed. note: the ?device parameter register? is ignored during flyby transaction. 9.7.5.2 how to program the GT-96100A for fly-by the dma control register has two bits for fly-by indications: 9.7.5.3 design considerations 1. device (fifos, fpga) must be fast enough to maintain read/write at sdram burst speed. 2. for ras to cas setting of 3 dmareq* must be deasserted within 3 tclk cycles following cstiming* assertion. 3. for ras to cas setting of 2 dmareq* must be deasserted within 2 tclk cycles following cstiming* assertion. 9.7.5.4 determining cs during fly-by bits [29:26,22] in the devicex (bank0, bank1, bank2, bank3 and boot) parameter registers are used to deter- mine which cs (chip select) are activated during flyby. ? dma channel 0 uses bits [29:26,22] of bank0 parameter register. ? dma channel 1 uses bits [29:26,22] of bank1. ? dma channel 2 uses bits [29:26,22] of bank2 ? dma channel 3 uses bits [29:26,22] of bank3. the interpretation of bits [29:26,22] is as follows: ? bit 22 low - bootcs* are the active cs. ? bit 26 low - cs0* are the active cs. ? bit 27 low - cs1* are the active cs. ? bit 28 low - cs2* are the active cs. ? bit 29 low - cs3* are the active cs. note: as a consequence of the nature of this mechanism, only one bit within bits [29:26,22] should be low. by default, bit 26 is low. this means cs0 is the active cs unless otherwise programmed. table 242: fly-by bits bit description flybyen dma accesses are fly-by, i.e., the data does not enter the internal fifo. flybydir determines if the device is the source or the destination. this bit affects the devrdwr* towards the device. note: the sdram address must be written to the source register of the dma channel, regardless of whether the sdram is the source or the destination. GT-96100A advanced communication controller 230 revision 1.0 9.8 initiating a dma from a timer/counter each channel can be programmed to have the dmareq* sourced from the external dmareq* pin or from the associated timer/counter. for example, dma channel 0 can only be enabled by timer/counter 0, dma channel 1 can only be enabled by timer/counter 1, etc. if bit 28 in the dma command register is set to 1, then when the timer/counter reaches the terminal count, an internal dmareq* is set and a new dma transfer is initiated. when this bit is set to 1, dmareq* is ignored. when set to 0, dmas are initiated by asserting dmareq*. initi- ating dma from timer/counter is enabled only in demand mode. 9.9 dma restrictions 1. in order to reprogram a channel after it has been enabled, it must first be checked that the dmaactst bit is set to not active (see table 236 ). if working in cde mode or eote mode then abr bit must be set to 1 along with en/dis bit. 2. when source or destination address is decremented, both addresses must be double-word-aligned (that is, a2. a1 and a0 should be all zero), and byte count must be a multiple of eight (this applies for burst limits greater than eight bytes). 3. burst reads of more than two double-words from pci devices have all byte enables (bes) active. this implies that dma read from pci i/o space must be aligned or with a burst limit no bigger that eight bytes, in order to avoid pci spec violation (pci spec defines correlation between two lsb address bits and byte enables on i/o transaction). 4. when using the address hold option in the source direction (see table 236 ), and sda bit is set to 1, the source and destination addresses must be double-word aligned. 5. when using the address hold option in the destination direction, both source and destination addresses must be double-word aligned. 6. records addresses (nptr) must be a multiple of 16 bytes. in chained mode, if the descriptors are stored in a device, the device must be 32 or 64 bit. if the descriptors are stored in sdram or in pci memory, there are no restrictions on the width of the resource. note: all descriptors must reside on word-aligned addresses. 7. no support for destination alignment (sda has no affect) when burst limit is 1, 2, or 4 bytes. 8. when dma accesses an unmapped address (see section 3.4 ?address space decoding errors? on page 63 ), it results in unpredictable behavior and the dma channel might need to be stopped by clearing the activate bit of the channel control register. 9. if the dma state machine has a pending read of the next descriptor and the descriptor is located in the pci space, any pci accesses to the dma registers are stopped. 10. if the pci master accessing the GT-96100A dma registers and the dma descriptors resides on the far side of a pci-to-pci bridge, a lock-up may occur because the pci requires that all writes must occur before any reads can take place across a pci-to-pci bridge. GT-96100A advanced communication controller revision 1.0 231 9.9.1 fly-by mode dma restrictions 1. the device and sdram must be the same width, 32 or 64 bit. 2. in fly-by transfers, byte_count must be a multiple of eight and source address must be word aligned. 3. the sdram cas latency must be programmed to 2. 4. srasprchg in all sdram parameter registers must pre-programed to 1(e.g. 3 cycles). 9.10 dma control registers table 243: dma control register map description offset page number dma record channel 0 dma byte count 0x800 page 232 channel 1 dma byte count 0x804 page 232 channel 2 dma byte count 0x808 page 232 channel 3 dma byte count 0x80c page 233 channel 0 dma source address 0x810 page 233 channel 1 dma source address 0x814 page 233 channel 2 dma source address 0x818 page 233 channel 3 dma source address 0x81c page 233 channel 0 dma destination address 0x820 page 233 channel 1 dma destination address 0x824 page 234 channel 2 dma destination address 0x828 page 234 channel 3 dma destination address 0x82c page 234 channel 0 next record pointer 0x830 page 234 channel 1 next record pointer 0x834 page 234 channel 2 next record pointer 0x838 page 235 channel 3 next record pointer 0x83c page 235 channel 0 current descriptor pointer 0x870 page 235 channel 1 current descriptor pointer 0x874 page 235 channel 2 current descriptor pointer 0x878 page 235 channel 3 current descriptor pointer 0x87c page 236 channel 0 control 0x840 page 236 channel 1 control 0x844 page 239 GT-96100A advanced communication controller 232 revision 1.0 9.10.1 dma record dma record channel 2 control 0x848 page 239 channel 3 control 0x84c page 239 dma arbiter arbiter control 0x860 page 240 table 244: channel 0 dma byte count, offset: 0x800 bits field name function initial value 15:0 bytect the number of bytes that are left in dma transfers. 0x0 31:16 byteremain if cde is set to 1 and the dma engine owns the descriptor (i.e. dma is currently in progress), the remaining bytes to trans- fer will be written. if the cpu owns the descriptor, these bytes can be written to any value. 0x0 table 245: channel 1 dma byte count, offset: 0x804 bits field name function initial value 31:0 various functions as in channel 0 dma byte count. 0x0 table 246: channel 2 dma byte count, offset: 0x808 bits field name function initial value 31:0 various functions as in channel 0 dma byte count. 0x0 table 243: dma control register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 233 table 247: channel 3 dma byte count, offset: 0x80c bits field name function initial value 31:0 various functions as in channel 0 dma byte count. 0x0 table 248: channel 0 dma source address, offset: 0x810 bits field name function initial value 31:0 srcadd the address from which the idma control- ler reads the data. 0x0 table 249: channel 1 dma source address, offset: 0x814 bits field name function initial value 31:0 srcadd the address from which the idma control- ler reads the data. 0x0 table 250: channel 2 dma source address, offset: 0x818 bits field name function initial value 31:0 srcadd the address from which the idma control- ler reads the data. 0x0 table 251: channel 3 dma source address, offset: 0x81c bits field name function initial value 31:0 srcadd the address from which the idma control- ler reads the data. 0x0 table 252: channel 0 dma destination address, offset: 0x820 bits field name function initial value 31:0 destadd the address to which the idma controller writes the data. 0x0 GT-96100A advanced communication controller 234 revision 1.0 table 253: channel 1 dma destination address, offset: 0x824 bits field name function initial value 31:0 destadd the address to which the idma controller writes the data. 0x0 table 254: channel 2 dma destination address, offset: 0x828 bits field name function initial value 31:0 destadd the address to which the idma controller writes the data. 0x0 table 255: channel 3 dma destination address, offset: 0x82c bits field name function initial value 31:0 destadd the address to which the idma controller writes the data. 0x0 table 256: channel 0 next record pointer, offset: 0x830 bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). note: the next record pointer must be 16 bytes aligned. this means bits [3:0] must be set to 0. 0x0 table 257: channel 1 next record pointer, offset: 0x834 bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). note: the next record pointer must be 16 bytes aligned. this means bits [3:0] must be set to 0. 0x0 GT-96100A advanced communication controller revision 1.0 235 table 258: channel 2 next record pointer, offset: 0x838 bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). note: the next record pointer must be 16 bytes aligned. this means bits [3:0] must be set to 0. 0x0 table 259: channel 3 next record pointer, offset: 0x83c bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). note: the next record pointer must be 16 bytes aligned. this means bits [3:0] must be set to 0. 0x0 table 260: current descriptor pointer 0, offset: 0x870 bits field name function initial value 31:0 cdptr0 channel 0 current address descriptor pointer 0x0 table 261: current descriptor pointer 1, offset: 0x874 bits field name function initial value 31:0 cdptr1 channel 1 current address descriptor pointer 0x0 table 262: current descriptor pointer 2, offset: 0x878 bits field name function initial value 31:0 cdptr2 channel 2 current address descriptor pointer 0x0 GT-96100A advanced communication controller 236 revision 1.0 9.10.2 dma channel control table 263: current descriptor pointer 3, offset: 0x87c bits field name function initial value 31:0 cdptr3 channel 3 current address descriptor pointer 0x0 table 264: channel 0 control, offset: 0x840 bits field name function initial value 0 flybyen data internal/external to dma fifo 0 - internal data is read from source address into dma fifo and written to destination address 1 - external (fly by) data is transferred to/from devices on sdram bus from/to sdram 0x0 1 rdwrfly sdram read/write meaningful only in fly-by mode. 0 - read from sdram 1 - write to sdram 0x0 3:2 srcdir source direction. 00 - increment source address 01 - decrement source address 10 - hold in the same value 11 - reserved 0x0 5:4 destdir destination direction. 00 - increment destination address 01 - decrement destination address 10 - hold in the same value 11 - reserved 0x0 8:6 dattranslim data transfer limit in each dma access. 101 - 1 byte 110 - 2 bytes 010 - 4 bytes 000 - 8 bytes 001 - 16 bytes 011 - 32 bytes 111 - 64 bytes 0x0 GT-96100A advanced communication controller revision 1.0 237 9 chainmod chained mode 0 - chained mode when a dma access is terminated, the parameters of the next dma access comes from a record in memory that is pointed to by the nextrecptr register. 1 - non-chained mode only uses the values programmed by the cpu (or pci) directly into the bytect, srcadd, and destadd registers. 0x0 10 intmode interrupt mode 0 - interrupt asserted every time the dma byte count reaches terminal count. 1 - interrupt every null pointer (in chained mode). 0x0 11 transmod transfer mode 0 - demand 1 - block 0x0 12 chanen channel enable 0 - disable 1 - enable 0x0 13 fetnexrec fetch next record 1 - forces a fetch of the next record, even if the current dma has not ended. this bit is reset after fetch is completed and is only meaningful in chained mode. 0x0 14 dmaactst dma activity status read only. assertion of this bit is caused by asserting chanen (bit 12). 0 - channel is not active. 1 - channel is active. 0x0 15 sda source destination alignment 0 - alignment is towards the source address. 1 - alignment is towards the destination address note: no support for destination align- ment when burst limit is 1, 2, or 4 bytes. 0x0 table 264: channel 0 control, offset: 0x840 (continued) bits field name function initial value GT-96100A advanced communication controller 238 revision 1.0 16 mdreq mask dma requests 0 - don?t mask 1 - mask dma requests for 3 cycles start- ing dma arbitration cycle. 0x0 17 cde close descriptor enable if enabled, dma writes remaining byte count to bits [31:16] of bytecount field in the descriptor. 0 - disable 1 - enable 0x0 18 eote end of transfer enable if enabled, dma transfer can be stopped in the middle of transfer using the eot signal. if dma channel is working in chain mode, this will cause fetching a new descriptor, otherwise the dma transfer is stopped. 0 - disable 1 - enable 0x0 19 eotie end of transfer interrupt enable if enabled and eot pin is asserted, dma generates an interrupt. 0 - disable 1 - enable 0x0 20 abr abort dma transfer this bit must be set if the cpu wants to stop and re-program dma, and cde (bit 17) and/or eote (bit 19) is set to 1. when the cpu issues this command, it must also set chanen (bit 12) to 0. 0 - no influence on channel behavior. 1 - abort dma. 0x0 22:21 slp override source address 00 - no override. use local address space for source 01 - source address is in pci_0 memory space. 10 - source address is in pci_1 memory space. 11 - reserved 0x0 table 264: channel 0 control, offset: 0x840 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 239 24:23 dlp override destination address 00 - no override. use local address space for destination. 01 - destination address is in pc_0 mem- ory space. 10 - destination address is in pci_1 mem- ory space. 11 - reserved 0x0 26:25 rlp override record address 00 - no override. use local address space for record. 01 - record address is in pci_0 memory space. 10 - record address is in pci_1 memory space. 11 - reserved 0x0 27 reserved 0x0 28 dmareqsrc dma request source 0 - request taken from dmareq* pin. 1 - request taken from timer/counter. 0x0 31:29 reserved 0x0 table 265: channel 1 control, offset: 0x844 bits field name function initial value 31:0 various fields function as in channel 0 control. 0x0 table 266: channel 2 control, offset: 0x848 bits field name function initial value 31:0 various fields function as in channel 0 control. 0x0 table 267: channel 3 control, offset: 0x84c bits field name function initial value 31:0 various fields function as in channel 0 control. 0x0 table 264: channel 0 control, offset: 0x840 (continued) bits field name function initial value GT-96100A advanced communication controller 240 revision 1.0 9.10.3 dma arbiter table 268: arbiter control, offset: 0x860 bits field name function initial value 1:0 priochan1/0 priority between channel 0 and channel 1. 00 - round robin 01 - priority to channel 1 over channel 0 10 - priority to channel 0 over channel 1 11 - reserved 0x0 3:2 priochan3/2 priority between channel 2 and channel 3. 00 - round robin 01 - priority to channel 3 over 2 10 - priority to channel 2 over 3 11 - reserved 0x0 5:4 priogrps priority between the group of channels 0/1 and the group of channels 2/3. 00 - round robin 01 - priority to channels 2/3 over 0/1 10 - priority to channels 0/1 over 2/3 11 - reserved 0x0 6 prioopt priority option enabled/disable 0 - high priority device relinquishes the bus for a requesting device for one dma transaction after it was serviced. 1 - high priority device is granted as long as it requests the bus. 0x0 31:7 reserved 0x0 GT-96100A advanced communication controller revision 1.0 241 10. pci a rbiter the GT-96100A integrates two pci arbiter functions. one is dedicated for pci_0 and the other for pci_1. the pci_0 arbiter handles up to six external agents and one internal agent (pci_0 master). the pci_1 arbiter sup- ports a total of four external agents in addition to the internal pci_1 master 1 . the pci arbiters implement a priority based weighted round robin (rr) arbitration mechanism. each agent is assigned a programmable priority tag (either high or low), and the arbitration is done according to these priori- ties. a simple round robin arbitration is performed within each priority level, while a weighted function is implemented for arbitrating between the high priority and the low priority groups. 10.1 interface figure 33: pci arbiter?s interface diagram 1. the internal design of the pci arbiter logic handles a total of 7 request/grant pairs for each of the arbiters. but, due to package limitations, the gt- 96100a is limited to a total of nine external request/grant pairs. these are divided between pci_0 arbiter and pci_1 arbiter. t hus, the user cannot connect six external agents to pci_0 arbiter and four external agents to pci_1 arbiter at the same time (it?s either 6 to pci_0 and 3 to pci_1, or 5 to pci_0 and 4 to pci_1). table 269: pci arbiter?s interface signal description pclk pci clock reset master reset interrupt interrupt note: this signal is asserted when the arbiter recognizes a ?broken? master (i.e. a master which does not respond to a grant signal assertion). gnt_[6:0] grant# output signals note: gnt_[0] of pci_0 arbiter is internally connected pci_0 master. the same holds for pci_1. req_[6:0] input req# signals. note: req_[0] of pci_0 arbiter is internally connected pci_0 master. the same holds for pci_1. gnt_[6:0] req_[6:0] frame_ irdy_ pci interrupt pclk reset arbiter GT-96100A advanced communication controller 242 revision 1.0 10.2 arbitration scheme as noted above, each of the pci arbiter?s requests has a user programmable priority level associated with it. two levels of priority are supported: high and low. pci bandwidth allocation per priority is programmable as well, enabling the user to optimize the pci to application needs. arbitration flow is shown in figure 34 . figure 34: pci arbitration flow frame_ pci frame# signal. irdy_ pci irdy# signal. table 269: pci arbiter?s interface (continued) signal description high_req? high_gnt high_cnt-- high_cnt>0? yes yes no low_req? low_gnt yes no no GT-96100A advanced communication controller revision 1.0 243 in relation to figure 34 , the following points should be noted: ? the two request signals (high_req, low_req) are generated by ?anding? each of the request lines with its respective priority attribute, and oring the results. for example: high_req = (req_[0] and (req_prio[0]==high)) or... (req_[1] and (req_prio[1]==high)) or... ? there is a counter associated with the priority scheme - high_cnt. the counter is used to assign differ- ent weights to each priority level. this is a count down counter that decrements each time a high priority request (high_req) is granted. when high_cnt expires, a slot is opened for low priority requests, and the counter is set to its preset value. ? each time a low priority request (low_req) is granted, high_cnt counter is preset. 10.3 arbitration parking the pci arbiter is designed to perform a default parking on the last agent granted. in order to overcome problems that happen with some pci devices that do not handle parking properly, there is an option to disable parking on a per pci master basis. this is done via the pci_arbiter_configuration register pd[6:0] bits. note: in addition to disabling parking to avoid issues with some problematic devices, the user must also dis- able parking on any unused request/grant pair. this is required to avoid possible parking on non existent pci masters. for example, if only 3 external agents are connected to pci_0 arbiter (using req0/gnt0, req1/gnt1, req2/gnt2 pins), then pd[6:4] should be set to 1. 10.4 pci arbiter configuration register table 270: pci_0 arbiter configuration register, offset: 0x101ae0 bits field name function initial value 0 gcen gap cycle enable when this bit is set to 1, the pci arbiter forces grant to be asserted only after the pci bus is idle. this guarantees two turn around cycles. 0 1 bden broken detection enable setting this bit to 1 enables the detection of broken master. a master is said to be broken if it fails to respond to grant assertion within a window speci- fied in bv (see bv description above). 0 GT-96100A advanced communication controller 244 revision 1.0 2 paen priority arbitration enable when this bit is set to 1, weighted round robin arbitration is performed between high priority and low priority groups. when this bit is reset, no round robin arbitration takes place and low priority requests are granted only when no high priority request is pending. note: if hppv is set to zero value and paen is 1, priority scheme is reversed. this means that high priority requests are granted only if no low priority request is pending. note: gap cycle must be enabled in the pci arbiter when working with priority arbitration. 0 6:3 bv broken value this value sets the maximum number of cycles that the arbiter waits for a pci master to respond to its grant assertion. if a pci master fails to assert frame* within this time, the pci arbiter aborts the transaction and per- forms a new arbitration cycle. in addition, a maskable interrupt is gener- ated. note: the pci arbiter waits for the current transaction to end before starting to count the wait-for-broken cycles. 0 13:7 p[6:0] priority these bits assign priority levels to the requests connected to the pci arbi- ter. when a pm bit is set to 1, priority of the associated request is high. the mapping between p bits and the request/grant pairs is similar to the one shown for pd bits above. 0 20:14 pd[6:0] parking disable these bits can be used to disable parking on any of the pci masters. when a pd is set to 1, parking on the associated pci master is disabled. the mapping between the pd bits and the request/grant pairs is as follows: ? pd[0] - internal pci master unit ? pd[1] - external req0/gnt0 ? pd[2] - external req1/gnt1 ? pd[3] - external req2/gnt2 ? pd[4] - external req3/gnt3 ? pd[5] - external req4/gnt4 ? pd[5] - external req5/gnt5 note: the arbiter parks on the last master granted unless disabled through the pd bit. also, if pd bits are all 1, the pci arbiter parks on the internal pci master. 0 28:21 hppv high priority preset value this is the preset value of the high priority counter (high_cnt). this counter decrements each time a high priority request is granted. when the counter reaches zero, it reloads with this preset value. the counter also reloads when a low priority request is granted. 0 table 270: pci_0 arbiter configuration register, offset: 0x101ae0 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 245 29 ar6en arbiter request 6 enable setting this bit enables the 6th request/grant pair connection to pci_0 arbi- ter. 0 - pins pb[4], pb[5] are connected to pci_1 arbiter and function as parb1_gnt4, parb1_req4. 1 - pins pb[4], pb[5] are connected to pci_0 arbiter and function as parb0_gnt6, parb0_req6. 0 30 gnt/ clk grant or otsclk this bit controls the function of pin pb6. 0 - this pin to function as otsclk1. 1- pb6 functions as pabr0_gnt4. 0 31 en enable setting this bit to 1 enables operation of the arbiter. when the arbiter is enabled, the internal pci_0 master is connected to it. the arbiter configuration must be set before the arbiter is enabled. this means two writes must be made to this register. the first write sets the arbiter configuration and must be done with the enable bit set to 0. with the second write, set the enable bit to 1 to enable operation of the arbiter. note: when the arbiter is enabled, pci req* and gnt* pins change their function: req* becomes grant (pci arbiter output) and gnt* becomes req (pci arbiter input). for example, enabling pci_0 arbiter causes (req0*,gnt0*) pair to function as (parb0_gnt1, parb0_req1) respectively. bv must be set to a value greater than zero, or else there will always be a break detection, as the arbiter waits 0 cycles for frame* assertion. 0 table 271: pci_1 arbiter configuration register, offset: 0x101ae4 bits field name function initial value 31:0 various similar to pci_0 arbiter configuration register (except for bit 30:29 which are reserved). 0 table 270: pci_0 arbiter configuration register, offset: 0x101ae0 (continued) bits field name function initial value GT-96100A advanced communication controller 246 revision 1.0 11. c ommunication i nterface u nit (ciu) the GT-96100A?s idma, ethernet ports, and sdma engines have one common interface with the other units within the GT-96100A. these other units include the cpu interface unit (punit), the memory control unit (dunit), and the pci unit (lunit). the common interface supports a single master, meaning that only one agent can gain control and access the memory (through the dunit) or the pci (through the lunit) at a time. in order to support this shared interface, the GT-96100A provides an arbitration mechanism, which arbitrates between requests generated by the idma, sdma, and ethernet. the arbitration logic supports multiple priority levels as well as different weights assigned to each priority level. the priority is programmable per request and the weights are programmable per priority. this arbitration mechanism also handles master type requests. master requests originate within the com- munication unit and are targeted at other units in the GT-96100A. for example, a request generated by one of the ethernet units and is targeted at the dunit (for sdram read/write access) is a master request. similarly, a request generated by the idma and is targeted at the pci unit is also a master request. the transactions asso- ciated with master requests are referred to as master transactions. in addition to handling master type requests and master transactions, the arbiter also handles slave transactions, which originate from other units within the GT-96100A (e.g. punit, lunit) and are targeted at the communication unit. slave requests are used by the other units to access internal registers within the communi- cation unit. arbitration between slave type requests is fixed and gives the highest priority to the punit (i.e. requests from cpu). the master/slave arbiter and the associated logic that handle the master/slave transactions are collec- tively called the communication interface unit (ciu). this section provides details about the arbitration scheme as well as high level design aspects of the ciu. GT-96100A advanced communication controller revision 1.0 247 11.1 ciu connectivity figure 35 shows a block diagram of the connectivity between the ciu and the communication unit agents. figure 35: ciu connection diagram a2ise_ad[63:0] ise2a_ad[63:0] a2idma_oe a2idma_req idma2a_ack a2idma_ack idma2a_req a2e1_oe a2e1_req e12a_ack a2e1_ack e12a_req a2e2_oe a2e2_req e22a_ack a2e2_ack e22a_req a2sdma_oe a2sdma_req sdma2a_ack a2sdma_ack sdma2a_req b b b b idma (from 64120) ether1 ether2 sdma a2x_ad[63:0] p2x_ad[63:0] p2a_req a2p_ack d2x_ad[63:0] a2d_req d2a_ack l2x_ad[63:0] a2l0_req l02a_ack l02a_req a2l0_ack a2l1_req l12a_ack l12a_req a2l1_ack b a2c_oe a2c_req c2a_ack mpscs punit dunit pci_0 pci_1 ciu p2x_ad[63:0] a2x_ad[63:0] p2a_req a2p_ack x2a_ack a2x_req p2x_ad[63:0] e2x_ad[63:0] p2e_req e2p_ack x2e_ack a2x_req p2x_ad[63:0] e2x_ad[63:0] p2e_req e2p_ack x2e_ack a2x_req p2x_ad[63:0] a2x_ad[63:0] p2a_req a2p_ack x2a_ack a2x_req p2x_ad[63:0] c2x_ad[63:0] p2c_req c2p_ack GT-96100A advanced communication controller 248 revision 1.0 11.2 address decoding and pci override (master) the GT-96100A?s ciu supports two types of master transactions - normal and pci override. for normal transactions, the ciu performs address decoding and access either the sdram/device or pci_0/ pci_1 based on the decoding result. see section 3. ?address space decoding? on page 56 for a description of the address decoding scheme. the pci override feature allows the user to direct all transactions from a specific communication agent to the pci_0 direction, overriding address decoding. the override feature is programmable for the idma, ethernet, sdma units. for information on activating this feature, see: ? idma: table 236 . ? ethernet: table 296 . ?sdma: table 316 . 11.2.1 address decoding errors the ciu is capable of handling transactions, which result in address decoding errors. if an address decoding error occurs, the ciu performs a dummy transaction with the initiating unit, discards the data, and sets the dmaout bit in the interrupt main_cause register, see table 391 . 11.3 arbitration scheme the ciu arbiter is designed to handle one transaction at a time. this could be either a master or slave trans- action. priority at the mater/slave level is fixed and gives higher priority to slave type transactions. the priorities are listed below (from high to low): ? punit - slave request from cpu (highest priority). ? l0unit - slave request from pci_0. ? l1unit - slave request from pci_1. ? master requests (lowest priority). arbitration within the master level is very flexible and is detailed in the following sections. 11.3.1 master arbitration the arbiter supports master requests from the following sources within the communication unit: ? idma, ? ethernet 1, ? ethernet 2, ?sdma 1, ?sdma 2. figure 36 depicts the arbiters? logical connectivity, for master requests. GT-96100A advanced communication controller revision 1.0 249 figure 36: arbiter connectivity each of the requests shown in figure 36 has a user programmable priority level associated with it. the three lev- els of priority are high, medium, low. in addition, bandwidth allocation per priority is programmable as well, providing the user with the capability to optimize memory access to application needs. arbitration flow is shown in figure 37 . idma_req idma_ack ether1_req ether1_ack ether2_req ether2_ack sdma1_req sdma1_ack sdma2_req sdma2_ack mem_req mem_ack (to dunit) master pci0_req pci0_ack (to lunit) arbiter pci1_req pci1_ack (to lunit) GT-96100A advanced communication controller 250 revision 1.0 figure 37: master arbitration flow high_req? high_gnt high_cnt-- high_cnt>0? yes yes med_req? med_gnt med_cnt-- med_cnt>0? yes no yes low_req? low_gnt yes no no no no GT-96100A advanced communication controller revision 1.0 251 in relation to figure 37 , note the following: ? the three request signals (high_req, med_req, low_req) are generated by anding each of the request lines shown in figure 36 with its respective priority attribute, and oring the results. for example - ? high_req = (idma_req and (idma_prio=high)) or (sdma_req1 and (sdma_prio1=high)) or... ? there are two counters associated with the priority scheme - high_cnt and med_cnt. these counters are used to assign different weights to each priority level. the counters are countdown based on the request being granted. each time a high priority request (high_req) is granted, the high priority counter (high_cnt) is decrement. when high_cnt reaches zero, a slot is opened for lower priority requests, and the counter is set to its preset value. the same holds for med_cnt. ? each time a lower priority request is granted, the higher level counters are preset. when a medium pri- ority request (med_req) is granted, high_cnt counter is preset. when a low priority request is granted, both high_cnt and med_cnt are preset. 11.4 ciu arbiter configuration register table 272: ciu arbiter configuration register, offset: 0x101ac0 bits field name function initial value 1:0 ipl idma priority level these bits assign the priority to the idma request according to the following: 11 - high priority 10 - medium priority 01 - low priority 00 - disabled (request is masked.) 0 3:2 epl1 ethernet port priority level 1 0 5:4 epl2 ethernet port priority level 2 0 7:6 spl1 sdma priority level 1 these bits assign the priority to the sdma request 1. see the ipl bit description in this table for details on pri- ority assignment. 0 9:8 spl2 sdma priority level 2 these bits assign the priority to the sdma request 2. see the ipl bit description in this table for details on pri- ority assignment. 0 15:10 reserved 0 GT-96100A advanced communication controller 252 revision 1.0 18:16 mppv medium priority preset value this is the preset value of the medium priority counter (med_cnt). when the counter reaches zero, it reloads with this preset value. note: if the medium priority counter is enabled (mpce bit set to 1), mppv value must not be set to zero. a value of zero in mppv is allowed only when the counter is disabled (i.e. when mpce = 0). 0 19 mpce medium priority counter enable when set, enables operation of the medium priority counter (med_cnt). when reset, the medium priority counter is disabled and low priority requests are only granted only when no medium priority request is pending. 0 22:20 hppv high priority preset value this is the preset value of the high priority counter (high_cnt). when the counter reaches zero, it reloads with this preset value. note: if the high priority counter is enabled (hpce bit set to 1), hppv value must not be set to zero. a zero value in hppv is allowed only when the counter is disabled (i.e. when hpce = 0). 0 23 hpce high priority counter enable when set, enables operation of the high priority counter (high_cnt). when reset, the high priority counter is disabled and lower priority requests are only granted when no high priority request is pending. 0 24 e0r ethernet unit 0 software reset 0 - resets the ethernet_1 unit 0 25 e1r ethernet unit 1 software reset 0 - resets the ethernet_1 unit w 0 30:26 reserved reserved. 0 31 bled big little endian for descriptors 0 - big endian 1 - little endian this bit controls the endianess of all descriptors han- dled by the ethernet dma and the serial dma (sdmas) engines. it does not affect the data portion - endianess of the data is controlled via the various dma configura- tion registers. 1 table 272: ciu arbiter configuration register, offset: 0x101ac0 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 253 12. 10/100m b e thernet u nit 12.1 functional overview the 10/100mb ethernet unit handles all functionality associated with moving packet data between local memory or pci and the ethernet ports. the unit in the GT-96100A is designed to support two independent 10/100mb ethernet ports. each 10/100 mbit port is fully compliant with the ieee 802.3 and 802.3u standards and integrates the mac function and a dual speed mii interface. the port?s speed (10 or 100mb/s) as well as the duplex mode (half or full duplex) is auto-negotiated through the phy and does not require user intervention. the port also features 802.3x flow-control mode for full-duplex and backpressure mode for half duplex. integrated address filtering logic provides support for up to 8k mac addresses. the address table resides in memory and a proprietary hash function is used for address table management. the address table functionality supports multicast as well as unicast address entries. an important feature related to the address recognition is igmp packet trapping mode. in this mode layer 3 hard- ware analysis is performed in order to check if a packet being received is an igmp packet. each packet identified as igmp is queued in the high priority queue of the port from which it was received. the igmp analysis is per- formed on the fly, so it does not impact bandwidth capability. another important feature related to priority queues is the type of service queuing algorithm. this algorithm is based on the decoding in layer 3 of the dscp field from the ip header. if enabled, the decoded field indexes a 64 entry ipt table in the ethernet register space. the 2-bit output of this table sets the priority queue of the received packet. the ethernet unit integrates powerful dma engines, which automatically manage data movement between buffer memory and the ports, and guarantee wire-speed operation on all ports (even when all ports are in 100mb full-duplex mode). there are two dma engines per port - one dedicated for receive and the other for transmit. the dma logic handles multiple priority queues per port, providing support for priority sensitive data in both directions. there are four receive priority queues and two transmit priority queues per port. priority information for received packets is either extracted from the packet tag (if the packet is vlan tagged) or from the destina- tion address entry in the address table (if the packet is not tagged) of the ip parameters as described above. the priority function is max (ip_parameters, vlan_tag, address_entry). GT-96100A advanced communication controller 254 revision 1.0 12.2 port features the 10/100mb ethernet port provides the following features: ? ieee 802.3 compliant mac layer function. ? ieee 802.3u compliant mii interface. ? 10/100mb operation - half and full duplex. ? flow control features: - ieee 802.3x flow-control for full-duplex operation mode. - backpressure for half duplex operation mode. ? internal and external loopback modes. ? transmit functions: - short frame (less than 64 bytes) zero padding. - long frames transmission (limited only by external memory size). - programmable values for ipg and blinder timers. - crc generation (programmable per packet). - automatic frame retransmission upon collision (with programmable retransmit limit). - backoff algorithm execution. - error report. ? receive functions: - 1/2k or 8k address filtering capability. - address filtering modes: - perfect filtering. - reverse filtering. - promiscuous mode. - broadcast reject mode. - igmp packet trapping (layer 3 analysis in hardware). - automatic discard of errored frames, short (less than 64 bytes) or collided. - reception of long frames (programmable up to 64kbytes). - crc checking. - pass bad frames mode. - error report. GT-96100A advanced communication controller revision 1.0 255 12.3 operational description 12.3.1 general overview the ethernet unit provides multiple ethernet ports functionality, with each port capable of running at either 10 or 100mb/s (half or full-duplex) independently of the other port. each port interfaces a mii phy on its serial side and manages packet data transfer between memory and mii. the data is stored in memory buffers, with any sin- gle packet spanning multiple buffers if necessary. upon completion of packet transmission or reception, a status report, which includes error indications, is written by the ethernet unit to the first or last descriptor associated with this packet. the buffers are allocated by the cpu and are managed through chained descriptor lists. each descriptor points to a single memory buffer and contains all the relevant information relating to that buffer (i.e. buffer size, buffer pointer, etc.) and a pointer to the next descriptor. data is read from buffer or written to the buffer according to information contained in the descriptor. whenever a new buffer is needed (end of buffer or end of packet), a new descriptor is automatically fetched and the data movement operation is continued using the new buffer. figure 38 shows an example of memory arrangement for a single packet using three buffers. figure 38: ethernet descriptors and buffers the following sections provide detailed information about the operation and user interface of the ethernet unit and its logic subsections. 12.3.2 transmit operation in order to initialize a transmit operation, the cpu must do the following: 1. prepare a chained list of descriptors and packet buffers. command/status buffer pointer next descriptor pointer buffer size/byte count 0 31 command/status buffer pointer next descriptor pointer buffer size/byte count 0 31 packet 1 - buffer 1 packet 1 - buffer 2 command/status buffer pointer next descriptor pointer buffer size/byte count packet 1 - buffer 3 descriptor 1 descriptor 2 descriptor 3 GT-96100A advanced communication controller 256 revision 1.0 note: the txdma supports two priority transmit queues - high and low. if the user wants to take advantage of this capability, a separate list of descriptors and buffers must be prepared for each of the priority queues. 2. write the pointer to the first descriptor to the dma?s current descriptor registers (txcdp) associated with the priority queue to be started. if both priority queues are needed, initialize txcdp for each queue. 3. initialize and enable the ethernet port by writing to the port?s configuration and command registers. 4. initialize and enable the dma by writing to the dma?s configuration and command registers. after completing these steps, the dma starts and performs arbitration between the transmit queues according to the value programmed in port_configuration_extend GT-96100A advanced communication controller revision 1.0 257 figure 39: ethernet packet transmission example 1. txcdp = transmit current descriptor pointer 0 31 command (f=1) buffer pointer next descriptor ptr byte count 0 31 command (l=1) buffer pointer next descriptor ptr byte count 0 31 command (f=1) buffer pointer next descriptor ptr byte count pkt 1 buf 1 pkt 1 buf 2 pkt 2 buf 1 txcdp (1) 0 31 command buffer pointer next descriptor ptr byte count 0 31 command buffer pointer next descriptor ptr byte count 0 31 command buffer pointer next descriptor ptr byte count 31 pkt 1 buf 1 pkt 1 buf 2 pkt 2 buf 1 txcdp 0 31 command buffer pointer next descriptor ptr byte count 0 31 status buffer pointer next descriptor ptr byte count 31 command buffer pointer next descriptor ptr byte count 31 pkt 1 buf 1 pkt 1 buf 2 pkt 2 buf 1 txcdp 1. packet 1 - transmitting 1st buffer 2. packet 1 - transmitting 2nd buffer 3. packet 2 - transmitting 1st buffer 11 1 011 001 GT-96100A advanced communication controller 258 revision 1.0 ownership of any descriptor other than the last is returned to cpu upon completion of data transfer from the buffer pointed by that descriptor. the last descriptor, however, is returned to cpu ownership only after the actual transmission of the packet is completed. while changing the ownership bit of the last descriptor, the dma also writes status information, which indicates any errors that might have happened during transmission of this packet. 12.3.2.1 retransmission (collision) full collision support is integrated into the ethernet port for half duplex operation mode. in half duplex operation mode, a collision event is indicated each time receive and transmit are active simulta- neously. when that happens, active transmission is stopped, jam pattern is transmitted and collision count for the packet increments. the packet is retransmitted after a waiting period, which conforms to the binary backoff algo- rithm specified in the ieee 802.3 standard. retransmit process continues for multiple collision events as long as a specified limit is not reached. this retransmit limit, which sets the maximum number or transmit retries for a single packet, is defined by the ieee 802.3 as 16. however, the user can program a different value (see table 296 for more details). the event of a single packet colliding 16 times is known as excessive collision . as long as a packet is being retransmitted, its last descriptor is kept under port ownership. when a successful transmission takes place (i.e. no collision), a status word containing collision information is written to the last descriptor and ownership is returned to cpu. if a retransmit limit is reached with no successful transmission, a status word with error indication is written to the packet?s last descriptor, and the transmit process continuous with the next packet. it is important to note that collision is considered legal only if it happens before transmitting the 65th byte of a packet. any collision event that happens outside the first 64 byte window is known as late collision , and is considered a fatal network error. late collision is reported to the cpu through packet status, and no retransmis- sion is done. note: a collision occurring during the transmission of the transmit packet?s last two bytes are not detected. 12.3.2.2 zero padding (for short packets) zero padding is a term used to denote the operation of adding zero bytes to a packet. this feature is used for cpu off-loading. the ethernet port offers a per packet padding request bit in the tx descriptor. this causes the port logic to enlarge packets shorter than 64 bytes by appending zero bytes. when this feature is used, only packets equal or larger than 64 bytes are transmitted as is. packets smaller than 64 bytes are zero padded and transmitted as 64 byte packets. 12.3.2.3 crc generation ethernet crc denotes four bytes of frame-check-sequence appended to each packet. crc logic is integrated into the port and can be used to automatically generate and append crc to a transmitted packet. one bit in the tx descriptor is used for specifying if crc generation is required for a specific packet. GT-96100A advanced communication controller revision 1.0 259 12.3.2.4 tx dma descriptors figure 40 depicts the format of tx dma descriptors. the following set of restrictions apply to tx descriptors: ? descriptor length is 4lw and it must be 4lw aligned (i.e. descriptor_address[3:0]=0000). ? descriptors may reside anywhere is cpu address space except for null address (0x00000000), which is used to indicate end of descriptor chain. ? last descriptor in the linked chain must have a null value in its nextdescriptorpointer field. ? tx buffers associated with tx descriptors are limited to 64k bytes and can reside anywhere in mem- ory. however, buffers with a payload smaller than 8 bytes must be aligned to 64-bit boundary. figure 41 illustrates possible alignments for 5 byte payload. figure 40: ethernet tx descriptor figure 41: ethernet tx buffer alignment restrictions (5 byte payload) table 273 through table 276 provide detailed information about the tx descriptor. 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 command / status reserved byte count buffer pointer next descriptor pointer 0 0 0 0 0 7 xx000000 xx001000 xx010000 xx011000 0 7 0 7 supported 0 7 alignment unsupported alignment unsupported alignment supported alignment binary addresses GT-96100A advanced communication controller 260 revision 1.0 table 273: ethernet tx descriptor - command/status word bits name description 31 o ownership bit when set to ?1?, the buffer is ?owned? by the device. when set to ?0?, the buffer is owned by the cpu. buffers owned by the cpu are not pro- cessed by the dma. 30 am auto mode when set, the dma does not clear the ownership bit at the end of buffer processing. 29:24 reserved. 23 ei enable interrupt the device generates a maskable txbuffer interrupt upon closing the descriptor. note: in order to limit the number of interrupts and prevent an interrupt per buffer situ- ation, the user should set this bit only in descriptors associated with last buff- ers. if this is done, txbuffer interrupt will be set only when transmission of a frame is completed. 22 gc generate crc when set, crc is generated and appended to this packet. note: valid only if l (bit 16) is set. 21:19 reserved. 18 p padding when this bit is set, zero bytes are appended to the packet if the packet is smaller than 60 bytes. use this feature to prevent transmission of fragments. note: valid only if l (bit 16) is set. 17 f first indicates first buffer of a packet. 16 l last indicates last buffer of a packet. 15 es error summary es = lc or ur or rl set by the device to indicate an error event that occured during packet the packet. note: valid only if l (bit 16) is set. 14 reserved. 13:10 rc[3:0] retransmit count. indicates actual number of retransmits for this packet. rc is valid only if l (bit 16) is set. 9 col collision when set, indicates that at least one collision event occured during transmission of the packet. note: valid only if l (bit 16) is set. GT-96100A advanced communication controller revision 1.0 261 8 rl retransmit limit (excessive collision) error indicates that retransmit count reached the limit specified in the dma configuration regis- ter, see table 296 ). note: valid only if l (bit 16) is set. 7 reserved. 6 ur under-run error indicates that part of the packet?s data was not available while transmission was in progress, probably due to memory access delays). note: valid only if l (bit 16) is set. 5 lc late collision error collision occurred outside the collision window (i.e. more than 512 bits were transmitted before collision assertion). note: valid only if l (bit 16) is set. 4:0 reserved table 274: ethernet tx descriptor - byte count bits name description 31:16 byte count number of bytes to be transmitted from associated buffer. this is the payload size in bytes. 15:0 reserved. table 275: ethernet tx descriptor - buffer pointer bits name description 31:0 buffer pointer 32-bit pointer to the beginning of the buffer associated with this descriptor. note: the alignment restrictions for buffers that have byte-count smaller than 8 bytes (see figure 41 on page 259 ). table 276: ethernet tx descriptor - next descriptor pointer bits name description 31:0 next descriptor pointer 32-bit pointer that points to the beginning of next descriptor. bits [3:0] must be set to 0. dma operation is stopped when a null (all zero) value in the next descriptor pointer field is encountered. table 273: ethernet tx descriptor - command/status word (continued) bits name description GT-96100A advanced communication controller 262 revision 1.0 12.3.2.5 tx dma pointer registers the tx dma employs a single 32-bit pointer register per queue: txcdp. ? txcdp - tx dma current descriptor pointer. txcdp is a 32-bit register used to point to the current descriptor of a transmit packet. the cpu must initialize this register before enabling dma operation. the value used for initialization should be the address of the first descriptor to use. 12.3.2.6 tx dma notes transmit dma process is packet oriented. the transmit dma does not close the last descriptor of a packet, until the packet has been fully transmitted. when closing the last descriptor, the dma writes packet transmission sta- tus to the command/status word and resets the ownership bit. a txbuffer maskable interrupt is generated if the ei bit in the last descriptor is set. transmit dma stops processing a tx queue whenever a descriptor with a null value in the next descriptor pointer field is reached or when a cpu owned descriptor is fetched. when that happens, a tx_end maskable interrupt is generated. in order to restart the queue, the cpu should issue a start_tx command by writing ?1? to the start_tx bit in the dma command register. 1 the transmit dma does not expect a null next descriptor pointer or a cpu owned descriptor in the middle of a packet. when that happens, the dma aborts transmission and stops queue processing. a tx_resource_error maskable interrupt is generated. in order to restart the queue, the cpu should issue a start_tx command. a transmit underrun occurs when the dma can not access the memory fast enough and packet data is not trans- ferred to the fifo before the fifo gets empty. in this case, the dma aborts transmission and closes the last descriptor with a ur bit set in the status word. also, a tx_underrun maskable interrupt is generated. transmit process continues with the next packet. in order to stop dma operation before the dma reaches the end of descriptor chain, the cpu should issue a stop command by writing ?1? to the stop_tx bit in the dma command register. the dma stops queue pro- cessing as soon as the current packet transmission is completed and its last descriptor returned to cpu owner- ship. in addition, a tx_end maskable interrupt is generated. in order to restart this queue, the cpu should issue a start_tx command. note: most of the terms used to denote either dma commands (start_tx and stop_tx) or interrupts (txbuffer, tx_end, tx_resource_error) actually reflect multiple terms (one per queue). for example, the GT-96100A provides two start_tx commands. there is a separate start_tx_high command, associ- ated with the high priority queue, and a start_tx_low command that is related to the low priority queue. the same applies to the other commands and interrupts listed above. 1. when the dma stops due to null descriptor pointer, the cpu has to write txcdp before issuing a start_tx command. otherwise, txcdp remains null and the dma can not restart queue processing. GT-96100A advanced communication controller revision 1.0 263 12.3.3 receive operation in order to initialize a receive operation, the cpu must do the following: 1. prepare a chained list of descriptors and packet buffers. note: the rxdma supports four priority queues. if the user wants to take advantage of this capability, a sep- arate list of descriptors and buffers should be prepared for each of the priority queues. 2. write the pointer to the first descriptor to the dma?s first and current descriptor registers (rxfdp, rxcdp) associated with the priority queue to be started. if multiple priority queues are needed, the user has to initialize txfdp and txcdp for each queue. 3. initialize and enable the ethernet port by writing to the port?s configuration and command registers. 4. initialize and enable the dma channel by writing to the dma?s configuration and command registers. after completing these steps, the port starts waiting for a receive frame to arrive at the mii interface. when this occurs, receive data is packed and transferred to the rxfifo. at the same time, address filtering test is done in order to decide if the packet is destined to this port. if the packet passes address filtering check, a decision is made regarding the destination queue to which this packet should be transferred. when this is done, actual data transfer to memory takes place. note: packets which fail address filtering are dropped and not transferred to memory. for packets that span more than one buffer in memory, the dma will fetch new descriptors as necessary. how- ever, the first descriptor pointer will not be changed until packet reception is done. when reception is completed, status is written to the first longword of the first descriptor, and the next descrip- tor?s address is written to both first and current descriptor pointer registers. this process is repeated for each received packet. notes: the rxcdp and rxfdp point to the same descriptor whenever the dma is ready for receiving a new packet. rxfdp is not modified during packet reception and points to the first descriptor. only after the packet had been fully received and status information was written to the first lw of the first descriptor, will the ownership bit be reset (i.e. descriptor returned to cpu ownership). ownership of any descriptor other than the first is returned to cpu upon completion of data transfer to the buffer pointed by that descriptor. this means that the first descriptor of a packet is the last descrip- tor to return to cpu ownership (per packet). 12.3.3.1 rx dma descriptors figure 42 shows the format of rx dma descriptors. the following set of restrictions apply to rx descriptors: ? descriptor length is 4lw and it must be 4lw aligned (i.e. descriptor_address[3:0]=0000). ? descriptors reside anywhere in the cpu address space except null address, which is used to indicate end of descriptor chain. ? rx buffers associated with rx descriptors are limited to 64k bytes and must be 64-bit aligned. mini- mum size for rx buffers is 8 bytes. GT-96100A advanced communication controller 264 revision 1.0 figure 42: ethernet rx dma descriptor table 277: ethernet rx descriptor - command/status word bits name description 0 ce crc error received crc does not match calculated crc for the received packet. note: valid only if f (bit 17) is set. 3:1 reserved. 4 col collision collision was sensed during packet reception. note: in normal operation mode collided packets are automatically discarded by the port (being shorter than 64 bytes). collided packets are accepted only when pbf is set in the port configuration register (see table 288 ). valid only if f (bit 17) is set. 5 lc reserved. 6 or overrun error indicates that the rx dma was unable to transfer data from rxfifo to memory fast enough, causing data overrun in the fifo. note: valid only if f (bit 17) is set. 7 mfl max frame length error indicates that a frame longer than max_frame_len was received. the maximum frame length is programmable (see table 289 ). note: valid only if f (bit 17) is set. 8 sf short frame error indicates that a frame shorter than 64 bytes was received. in normal operation mode short packets are automatically discarded by the port. short packets are accepted only when pbf is set in the port configuration register (see table 288 ). note: valid only if f (bit 17) is set. 10:9 reserved. 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 byte count buffer size buffer pointer next descriptor pointer 0 0 00 0 0 command / status 0 0 0 0 GT-96100A advanced communication controller revision 1.0 265 11 ft frame type ? 1 - 802.3 ? 0 - ethernet set to ?1? when the type/length field in the received packet has a value not bigger than 1500 (decimal). note: valid only if f (bit 17) is set. 12 m missed frame ? 0 - match ?1 - miss set to indicate that this packet?s destination address is not found in the address table. this bit may be set if hdm or pm are set in the port configuration register (see table 288 ). also, set to receive broadcast packets regardless of the hdm or pm settings in the port configuration register. note: this bit is valid only if f (bit 17) is set. 13 he hash table expired set to indicate that hash process was not completed in time. this means there is no defi- nite answer as to whether this packet?s address is in the hash table or not. also, set when there is no room in the table for this address. note: valid only if f (bit 17) is set. 14 igmp set to indicate that this packet has been identified as an igmp packet. note: valid only if f (bit 17) is set. 15 es error summary es = ce or col or lc or or or mfl or sf note: valid only if f (bit 17) is set. 16 l last indicates last buffer of a packet. 17 f first indicates first buffer of a packet. 22:18 reserved. 23 ei enable interrupt the device generates a maskable interrupt upon closing the descriptor. note: in order to limit the number of interrupts and prevent an interrupt per buffer situ- ation, the user should set the ei bits in all the rx descriptors and set rifb bit in the dma configuration register (see table 296 ). the rxbuffer interrupt is set only on frame (rather than buffer) boundaries. 29:24 reserved. 30 am auto mode when set, the dma does not clear the ownership bit at the end of buffer processing. table 277: ethernet rx descriptor - command/status word (continued) bits name description GT-96100A advanced communication controller 266 revision 1.0 31 o ownership bit. when set to ?1?, the buffer is ?owned? by the device. when set to ?0?, the buffer is owned by cpu. table 278: ethernet rx descriptor - buffer size / byte count bits name description 15:0 byte count when the descriptor is closed this field is written by the device with a value indicating number of bytes actually written by the dma into the buffer. 31:16 buffer size buffer size in bytes when number of bytes written to this buffer is equal to buffer size value, the dma closes the descriptor and moves to the next descriptor. note: bits [18:16] must be set to 0. table 279: ethernet rx descriptor - buffer pointer bits name description 31:0 buffer pointer 32-bit pointer to the beginning of the buffer associated with the descriptor rx buffers have to be 64-bit aligned, so bits [2:0] must be set to 0. table 280: ethernet rx descriptor - next descriptor pointer bits name description 31:0 next descriptor pointer 32-bit next descriptor pointer to the beginning of next descriptor bits [3:0] must be set to 0. dma operation is stopped when a null value in the next descriptor pointer field is encountered. table 277: ethernet rx descriptor - command/status word (continued) bits name description GT-96100A advanced communication controller revision 1.0 267 12.3.3.2 rx dma pointer registers the rx dma employs two 32-bit pointer registers per queue: rxfdp and rxcdp. ? rxfdp - rx dma first descriptor pointer. rxfdp is a 32-bit register used to point to the first descriptor of a receive packet. the cpu must initial- ize this register before enabling dma operation. the value used for initialization should be the address of the first descriptor to use. ? rxcdp - rx dma current descriptor pointer. rxcdp is a 32-bit register used to point to the current descriptor of a receive packet. the cpu must ini- tialize this register before enabling dma operation. the value used for initialization should be the same as the value used for initializing rxfdp (i.e. address of first descriptor to use). 12.3.3.3 type of service queueing the type of service queuing algorithm is based on the decoding of the dscp field from the ip header. the dscp field is located in the 6-msb bits of the second byte in the ip header (see figure 43 ). this field indexes the 64 ipt table entries, which reside in the GT-96100A ethernet register space. the 2-bit priority output of this table is referred to in the algorithm as tos_priority . the tos_priority is valid only if the tos2prio enable bit 21 in the ethernet port configuration extend register, referred to in the algorithm as tos2prio_en, is set. if a vlan tag exists in the packet, the vlan priority tag is decoded from the 3-msb bits of the 2 nd word in the vlan tag. this field is the index to the 8 entries in the vpt table, which reside in the GT-96100A ethernet reg- ister space. the 2-bit priority output of this table is referred to in the algorithm as vlan_priority . the GT-96100A can decode bpdu and igmp protocol packets. these packets are referred to in the algorithm as frame_bpdu and frame_igmp respectively. protocol detection is controlled by the span and igmp bits in the ethernet port configuration extend register, referred to in the algorithm as bpdu_captue and igmp_capture respectively. bpdu and igmp protocol packets are sent to the highest value queue unless protocol detection is turned off. the priorx override bit in the ethernet port configuration extend register, referred to in the algorithm as overide_priority, takes precedence over tos_priority or vlan_priority . if this bit is set, all packets (except frame _ bpdu and frame_igmp ) are sent to the default_priority queue. the algorithm notation for the priorx 2- bit field in the ethernet port configuration extend register is default_priority . the packet type is checked after checking the source address, vlan tag (if it exists), and llc-snap (if it exists). the packet type is compared to 0x8100, referred to in the algorithm as vlan_type, or to 0x800, referred to in the algorithm as ip_type . if vlan_type or ip_type with valid tos_priority, or both, are found on the packet, the packet is referred to in the algorithm as frame_tagged . broadcast packets, which are referred to in the algorithm as frame_broadcast and are not marked as frame_tagged are also sent to the default_priority queue. if the packet is marked as frame_tagged , the GT-96100A sends the packet to the tos_priority queue or vlan_priority queue. if both tos_priority and vlan_priority are extracted from the packet, the GT-96100A sends the packet to the higher value queue. GT-96100A advanced communication controller 268 revision 1.0 if both tos_priority and vlan_priority are missing from the packet, the GT-96100A uses the priority value found in the matched hash table entry. the hash table entry match, referred to in the algorithm as da_found , occurs when the destination address matches the entry?s address and the entry is valid. the 2-bit priority value, referred to in the algorithm as ht_priority , is located on bits 52:51 of the hash table entry. the address to be compared is located on bits 50:3 of the hash table entry. the validity of the entry is stated in bits 2:0. when the hash table entry does not return a priority value, the packet is sent to the default_priority queue. figure 43: type of service queueing algorithm ethernet packet da sa vlan (opt.) type/length llc-snap (opt.) ip header data crc 63 0 hash table entry (in memory) 15 0 15 0 0x8100 vlan_priority[1:0] vpt table entry (in 96100 registers) bits15:13 priority index 707015 0 version length tos_priority[1:0] ipt table entry (in 96100 registers) bits7:2 priority index if ((frame_bpdu & bpdu_capture) | (frame_igmp & igmp_capture)) queue = 3; // highest else if (overide_priority || (frame_broadcast & !tagged_frame)) queue = default_priority; else if (tagged_frame) queue = (tos_priority > vlan_priority)? tos_priority : vlan_priority; else if (da_found) queue = ht_priority; else queue = default_priority; frame_bpdu = (da == bpdu address) frame_broadcast = (da == broadcast address) frame_igmp = (ip header == igmp protocol) bpdu_capture, igmp_capture, overide_priority, and default_priority are option bits in the 96100 registers. da_found = bit2:0 && (da == bits50:3) bits52:51 ht_priority[1:0] frame_tagged = (vlan_type found || (ip_type found && tos2prio_en)) type of service receive queuing algorithm in the GT-96100A registry in the GT-96100A registry GT-96100A GT-96100A advanced communication controller revision 1.0 269 12.3.3.4 rx dma notes the receive dma process is packet oriented. the dma does not close the first descriptor of a packet, until the last descriptor of the packet is closed. when closing the first descriptor, the dma writes status to the command/ status word and resets the ownership bit. a rxbuffer maskable interrupt is generated if the ei bit in the first descriptor is set. the receive dma never expects a null next descriptor pointer or a cpu owned descriptor during normal oper- ation. it is assumed that whenever the receive dma needs a buffer, a buffer is ready for it. if this is not the case, the rxdma engine stops serving the current priority queue and a rx_resource_error maskable interrupt is gen- erated. to resume operation of the stopped queue, the following must be performed: 1. read the rxcdp associated with the stopped queue. 2. if rxcdp is not null, it means that the error is due to a cpu owned descriptor. in this case, flip the ownership bit of the descriptor pointed by rxcdp. 3. if rxcdp is null, it means that the error is due to a null descriptor pointer. in this case, re-initialize the queue by writing a valid pointer to both rxcdp and rxfdp. stopping rx dma operation is possible using the rx_abort command (see table 297 ). 12.3.4 ethernet address recognition the following chapter describes the hash algorithm and hash table data structure. the cpu must build this table for the GT-96100A before enabling the ethernet port. 12.3.4.1 hash table structure the GT-96100A hash table is a data structure prepared by the cpu and resides in the system dram. its location is identified by a 32 bit pointer stored in the GT-96100A ehtp internal register (addresses 0x84828 and 0x88828). the hash table must be octet-byte aligned. the lowest three bits of the ehtp register are hard wired to ?0?. there are two possible sizes for the hash table. table size is selected by the hs bit in the ethernet configuration register (pcr, address 0x84800 and 0x88800). ? 8k address table. 256kbyte of dram required (4 x 64kbyte banks) ? 1/2k address table. 16kbyte of dram required (4 x 4kbyte banks) a multiple of 4 banks are used in order to reduce the number of addresses that are mapped to the same table entry. note: the user must initialize the hash table before enabling the ethernet controller. each address entry is a two word data field (64 bits) as shown below: GT-96100A advanced communication controller 270 revision 1.0 figure 44: ethernet hash table entry the following table describes the hash table entry fields. table 281: hash table entry fields bit command usage 0 valid indicates valid entry 1 skip skip empty entry in a chain 2 receive/discard (rd) 0 - discard packet upon match 1 - receive packet upon match 6:3 ethernet address[3:0] mapped to ethernet mac address[43:40]. 11:7 ethernet address[7:4] mapped to ethernet mac address[47:44]. 14:11 ethernet address[11:8] mapped to ethernet mac address[35:32]. 18:15 ethernet address[15:12] mapped to ethernet mac address[39:36]. 22:19 ethernet address[19:16] mapped to ethernet mac address[27:24]. 26:23 ethernet address[23:20] mapped to ethernet mac address[31:28]. 30:27 ethernet address[27:24] mapped to ethernet mac address[19:16]. 34:31 ethernet address[31:28] mapped to ethernet mac address[23:20]. 38:35 ethernet address[35:32] mapped to ethernet mac address[11:8]. 42:39 ethernet address[39:36] mapped to ethernet mac address[15:12]. 46:43 ethernet address[43:40] mapped to ethernet mac address[3:0]. 50:47 ethernet address[47:44] mapped to ethernet mac address[7:4]. 52:51 priority the priority queue of a packet sent to this ethernet address, in case there are no other priority signals (i.e. tos or vlan). 63:53 reserved fill with ?0? add+0x4 add+0x0 entry parameters ethernet address reserved (fill with ?0?) 0 31 32 63 GT-96100A advanced communication controller revision 1.0 271 12.3.4.2 hash modes there are two hash functions in the GT-96100A; hash mode 1 and hash mode 0. 12.3.4.3 hash mode 0 in hash mode 0, the hash entry address is calculated in the following manner: hashresult[14:0] = hashfunc0(ethernetadd[47:0]) ? hashresult is the 15 bits hash entry address. ? ethernetadd is a 48 bit number, which is derived from the ethernet mac address, by nibble swapping in every byte; i.e. mac address of 0x123456789abc translates to ethernetadd of 0x21436587a9cb. ? inverse every nibble; i.e. ethernetadd of 0x21436587a9cb translates to 0x482c6a1e59d hashfunc0 calculates the hashresult in the following manner: ? hashresult[14:9] = ethernetadd[7:2] ? hashresult[8:0]= ethernetadd[14:8,1,0] xor ethernetadd[23:15] xor ethernetadd[32:24] 12.3.4.4 hash mode 1 in hash mode 1, the hash entry address is calculated in the following manner: hashresult[14:0] = hashfunc1(ethernetadd[47:0]) ? hashresult is the 15 bits hash entry address. ? ethernetadd is a 48 bit number, which is derived from the ethernet mac address, by nibble swapping in every byte (i.e mac address of 0x123456789abc translates to ethernetadd of 0x21436587a9cb). ? inverse every nibble; i.e. ethernetadd of 0x21436587a9cb translates to 0x482c6a1e59d hashfunc1 calculates the hashresult in the following manner: ? hashresult[14:9] = ethernetadd[0:5] ? hashresult[8:0]= ethernetadd[6:14] xor ethernetadd[15:23] xor ethernetadd[24:32] 12.3.4.5 hash entry for each ethernet address, the hash table entry address is the lower 13 bits of the hashresult for the 8kbyte address table, or the lower 9 bits for the 0.5kbyte address table. the entry is an offset from the address base and is octet-byte aligned. the address entry is therefore: ? 8k address table: tblentryadd = ehtp + {hashresult[14:0],000} ? 1/2k address table:tblentryadd = ehtp + {hashresult[10:0],000} 12.3.4.6 hash table numbers 12.3.4.7 table filling when preparing the hash table data structure, the cpu must first (typically at boot time) initialize the hash table memory to ?0?. the table filling algorithm is described below. the hopnumber should be selected and initialized before entering this routine. the hash table hopnumber (number of hops) is 12. after 12 tries to identify an address, the gt- 96100a passes the address to the cpu and sets the he (hash expired) bit in the descriptor status field. there- fore, the hopnumber is the number of times the cpu will attempt to write a newly learned ethernet address into the hash table. GT-96100A advanced communication controller 272 revision 1.0 ? calculate tblentryadd according to mode of operation (hash mode 1 or hash mode 0). ? check that tblentry is empty (valid bit is "0"). ? if the tblentry is empty, write the hashentry (valid, skip and rd bits and ethernet address). ? if the tblentry is occupied (i.e. valid bit is 1 and skip bit is 0), move to tblentry+1. ? if less than hopnumber tries, repeat to step c. if after hopnumber failed tries, the cpu has been unable to located a free table entry. the cpu can then: ? defragment the table. ? create a new hash table using the alternate hash mode, which may redistribute the addresses more evenly in the table. in cases where more than one address is mapped to the same table entry, an address chain is created. in this case, when the cpu needs to erase an address that is part of an address chain, it cannot clear its valid bit since this would cut the chain. instead, the cpu should set the skip bit to ?1?. this is shown in table 45 . figure 45: address chain 12.3.4.8 address recognition process the following terms are used when referring to the address recognition process. ? match - address is found in the table ? miss - address is not found in the table ? hit - address is in the table and rd bit is 1 (receive), or address is not in table and hdm (hash default mode) is 1 (receive). ? occupied entry - a valid hash table entry that is occupied by another address, or an entry that has its skip bit set, ? promiscuous mode - when enabled, all packets are passed to the cpu. the GT-96100A still executes the hash process reporting to the cpu, regardless whether the address is in the hash table or not. the GT-96100A address recognition process is described below, and is illustrated by figure 46 on page 274 . the process starts with the GT-96100A fetching the address from the calculated table entry. add1 add2 add3 add6 add4 add5 add1 add2 add3 add6 add4 add5 ab in case a where add1-6 has the same hash function, and thus start with the same tblentry, the cpu allo- cates them in the table by increasing tblentry by one entry each time. add1 is the first address to be writ- ten into the table and add6 is the last. when the cpu is required to remove add2 from the table, it cannot clear its valid bit since that would break the chain from add1 to add3. instead, it sets add2?s skip bit to ?1? (denoted as ). it is also rec- ommended that the cpu defragments the table from time to time. GT-96100A advanced communication controller revision 1.0 273 ? if occupied entry is encountered, the GT-96100A proceeds to the next hash table entry. ? after hopnumber failed tries, the GT-96100A passes the packet to the cpu and marks it by setting the he bit in the descriptor. the same process is used in case the discard window is over, or the frame ends before the GT-96100A accomplishes the hash process (which happens in rare situations when the gt- 96100a cannot gain enough access to the dram). ? when the GT-96100A finds the address in the table there is a match. ? when the GT-96100A encounters an empty entry, there is a miss, meaning that the address is not in the table. ? in case of a match, and if the rd bit is set, then there is a hit. the GT-96100A marks the packet by set- ting the m bit of the receive descriptor. ? in case of a miss, and if the hdm bit is set, then there is also a hit. the GT-96100A marks the packet by setting the m bit of the receive descriptor. ? if there was no hit, then the packet should be discarded. however, packets will pass if promiscuous mode is enabled. GT-96100A advanced communication controller 274 revision 1.0 figure 46: address filtering process start not valid entry or skip? hopnumber expired? set he bit in descriptor pass frame end address found in table (match) rd bit set in table entry hdm set? promiscous mode? discard frame set m bit in descriptor no no yes yes yes yes yes no n o no yes calculate hash and fetch address no GT-96100A advanced communication controller revision 1.0 275 the GT-96100A uses the he (hash expired) and m (match) bits in the descriptor for reporting the packet filter- ing status. table 282 describes the various reports and summarizes their meaning. 12.4 ethernet port 12.4.1 network interface the ethernet port interfaces directly to a mii (media independent interface) phy compliant with the ieee stan- dard (please refer to ieee 802.3u fast ethernet standard for detailed interface and timing information). the mii port has the following characteristics: ? capable of supporting both 10 mbps and 100 mbps data rates in half or full duplex modes. ? data and delimiters are synchronous to clock references. ? provides independent 4-bit wide transmit and receive paths. ? uses ttl signal levels. ? provides a simple management interface (common to all ports). ? capable of driving a limited length of shielded cable. the port incorporates all the required digital circuitry to interface with a 100basetx, 100baset4, and 100basefx mii phys. 12.4.1.1 10/100 mii/rmii compatible interface the port?s mac (media access control) logic supports connection to a 10mbps or 100mbps network. the mii interface consists of a separate nibble-wide stream for both transmit and receive data. data transfers are clocked by the 25 mhz transmit and receive clocks in 100 mbps operation, or by 2.5 mhz transmit and receive clocks in 10 mbps operation. the clock inputs are driven by the phy, which controls the clock rate according to the network connection speed. the rmii interface consists of a separate 2bit-wide stream for both transmit and receive data. data transfers are clocked by the 50 mhz clock in both 100 mbps and 10 mbps operation. the clock input is driven by an external source. table 282: packet filtering status he m condition 0 0 hash table no hit the address was not found in the hash table, but promiscuous mode is enabled 0 1 hash table hit either by an address found in the hash table and rd bit set or by an address that was not found in the hash table, in case that hdm bit is set 1 0 hash table expired the hopnumber expired before the address was found in the hash table 11unused GT-96100A advanced communication controller 276 revision 1.0 12.4.1.2 media access control (mac) the mac logic performs all of the functions of the 802.3 protocol such as frame formatting, frame stripping, col- lision handling, deferral to link traffic, etc. it also ensures that any outgoing packet complies with the 802.3 spec- ification in terms of preamble structure - 56 preamble bits are transmitted before start of frame delimiter (sfd). the mac operates in half duplex or full duplex modes. in half duplex mode, the mac?s transmit logic checks that there is no competitor for the network media before transmission. in addition to waiting for idle before transmitting, the port handles collisions in a predetermined way. if two nodes attempt to transmit at the same time, the signals collide and the data on the line is garbled. the port listens while it is transmitting, and can detect a collision. if a collision is detected, ?jam? pattern is transmitted and retransmission is delayed for a random time period determined by the backoff algorithm. in full-duplex mode, the port transmits unconditionally. 12.4.1.3 auto-negotiation for duplex mode the port?s duplex operation mode (either half or full duplex) can be auto-negotiated or set by the cpu. in order to enable auto-negotiation for duplex, the cpu must set the port_configuration_extend GT-96100A advanced communication controller revision 1.0 277 5. resolve the duplex mode of the two link partners in the following manner: if ((ability == ?100base-tx full duplex?) or (ability == ?10base-t full duplex?)) then duplex mode = full duplex else duplex mode = half duplex; continue to step 6. 6. update the port_status register by writing the correct duplex mode bit. continue with step 1. 12.4.1.4 auto-negotiation for flow control flow control mode (either enabled or disabled) can be auto-negotiated or set by the cpu. in order to enable auto- negotiation for flow-control, the cpu should set port_configuration_extend GT-96100A advanced communication controller 278 revision 1.0 12.4.1.6 data blinder the data blinder field (datablind in the serial_parameters register) sets the period of time during which the port does not sense the wire before transmission (inhibit time). the default value is 32 bit times. 12.4.1.7 inter packet gap (ipg) ipg is the minimum idle time between transmission of any two successive packets from the same port. the default (from the standard) is 9.6us for 10mbps ethernet and 960nsec for 100-mbps fast ethernet. note that the ipg can be made smaller or larger than standard definition by programming the serial_parameters register. 12.4.1.8 10/100 mbps mii transmission when the port has a frame ready for transmission, it samples link activity indicators. if the crs signal is inactive (no activity on the link), and the inter-packet gap (ipg) timer had expired, frame transmission begins. the data is transmitted via pins txd[3:0] of the transmitting port, clocked on the rising edge of txclk. the signal txen is asserted at this same time. in the case of collision, the phy asserts the col signal causing the port to stop trans- mitting the frame and append a jam pattern to the transmitted bit stream. at the end of a collided transmission, the port will back off and attempt to retransmit once the backoff counter expires. per the ieee 802.3 specifica- tion, the clock to output delay must be a minimum of 0ns and a maximum of 25ns as shown in figure 48 . 12.4.1.9 10/100 mbps rmii transmission the port starts transmission when it has a frame ready, and inter-packet gap (ipg) timer has expired. if in half_duplex mode, it also samples crs_dv indicator for no activity. the data is transmitted via pins txd[1:0] of the transmitting port, clocked on the rising edge of ref_clk and the signal tx_en is asserted. in half_duplex mode, in the case of collision (tx_en asserted with crs_dv), the port stops transmitting the frame and appends a jam pattern to the transmitted bit stream. at the end of a collided transmission, the port backs off and attempts to retransmit once the backoff counter expires. as the ref_clk frequency is 10 times the data rate in 10 mbps, the value on txd[1:0] shall be valid so that it may be sampled every 10th cycle. for the rmii, transmission of each octet shall be done a di-bit at a time as per the order described in the figure 47 . 12.4.1.10 10/100 mbps rmii reception frame reception starts with the assertion of crs_dv by the phy. the port begins sampling incoming data on pins rxd[1:0] on the rising edge of ref_clk. reception ends when crs_dv is deasserted by the phy. the last di-bit sampled by the port is the data present on rxd[1:0] on the last ref_clk rising edge in which crs_dv is still asserted. crs_dv is continuously asserted during reception. if an error is detected while crs_dv is asserted, the decoded data is replaced in the receiving stream with "01" until the end of carrier activ- ity. by replacing the data in the remainder of the frame, the crc check is guaranteed to reject the packet as an error. when no reception takes place, crs_dv should remain de-asserted. as the ref_clk frequency is 10 times the data rate in 10 mbps, the value of each octet shall be valid so that it may be sampled every 10th cycle. for the rmii, reception of each octet shall be done a di-bit at a time as per the order described in figure 47 . GT-96100A advanced communication controller revision 1.0 279 the rmii transmission and reception of each octet is described in figure 47 . figure 47: rmii di-bit stream figure 48: mii transmit signal timing 12.4.1.11 10/100 mbps mii reception frame reception starts with the assertion of crs (while the port is not transmitting) by the phy. once rxdv is asserted, the port begins sampling incoming data on pins rxd[3:0] on the rising edge of rxclk. reception ends when rxdv is deasserted by the phy. the last nibble sampled by the port is the nibble present on rxd[3:0] on the last rxclk rising edge in which rxdv is still asserted. during reception rxdv is continu- ously asserted. if, while rxdv is asserted, rxer is asserted, it designates current packet as corrupted. when no reception takes place, rxdv should remain deasserted. the input setup time should be a minimum of 10ns and the input hold time must be a minimum of 10ns and shown in figure 49 . d0 d1 d2 d3 d4 d5 d6 d7 mac's serial bit stream first bit first nibble second nibble d0 d1 txd[0]/rxd[0] txd[1]/rxd[1] rmii di-bit stream 0ns min 25ns max txclk txd, txen vih min vil max vih min vil max GT-96100A advanced communication controller 280 revision 1.0 figure 49: mii receive signal timing 12.4.1.12 10/100 mbps full-duplex operation when operating in full-duplex mode the port can transmit and receive frames simultaneously. in full-duplex mode, the crs signal is associated with received frames only and has no effect on transmitted frames. the col signal is ignored while in full-duplex mode. transmission starts when txen goes active. trans- mission starts regardless of the state of crs. reception starts when the crs signal is asserted indicating traffic on the receive port of the phy. 12.4.1.13 back pressure the port implements a back pressure algorithm, which is only for use when the port is operating in half duplex mode. it is enabled through port_command GT-96100A advanced communication controller revision 1.0 281 12.4.2 mii serial management interface (smi) the ethernet unit has an integrated mii serial management interface (smi) logic for controlling mii compliant phys. this interface consists of two signals: serial data (mdio); and, clock (mdc). these signals enable control and status parameters to be passed between the phys and the port logic (or cpu). multiple phy devices can be controlled using this simple 2-pin interface. typically, the smi unit continuously queries the phy devices for their link status, without the need for cpu intervention. the phy addresses for the link query operation are programmable per port in the phy_address register. a cpu can write/read to/from all phy addresses/registers by writing and reading to/from the smi control regis- ter. the smi allows the cpu to directly control a mii compatible phy device via the smi control register. this enables the driver software to program the phy into specific operation mode such as full duplex, loopback, power down, 10/100 speed selection as well as control of the phy device?s auto-negotiation function, if it exists. the cpu writes commands to the smi register and the smi unit performs the actual data transfer via mdio, which is a bi-directional data pin. these serial data transfers are clocked by the mdc clock output. 12.4.2.1 mii management frame structure the GT-96100A?s smi cycles support the mii management frame structure. frames transmitted on the mii management interface have a structure that is shown in table 283 and the order of bit transmission is from left to right. the format of the bit transmission?s parts is as follows: table 283: mii management frame format pre st op phyad regad ta data idle read 1...1 01 10 aaaaa rrrrr z0 d...d(16) z write 1...1 01 01 aaaaa rrrrr 10 d...d(16) z table 284: bit transmission parts part description pre (preamble) at the beginning of each transaction, the port sends a sequence of 32 contigu- ous logic one bits on mdio with 32 corresponding cycles on mdc to provide the phy with a pattern that it can use to establish synchronization. st (start of frame) a start of frame pattern of 01. op (operation code) 10 - read; 01 - write . phyad (phy address) a 5 bit address of the phy device (32 possible addresses). the first phy address bit transmitted by the port is the msb of the address. regad (register address) a 5 bit address of the phy register (32 possible registers in each phy). the first register address bit transmitted by the port is the msb of the address. the port always queries the phy device for status of the link by reading register 1 bit 2. GT-96100A advanced communication controller 282 revision 1.0 12.4.3 smi timing requirements when the mdio signal is driven by the phy, it is sampled synchronously with respect to the rising edge of mdc. per ieee 802.3 specification, the mdc to output delay must be a minimum of 0ns and a maximum of 300ns as shown in figure 10. further, when the mdio signal is driven by the port, it has a minimum of 10ns setup time and minimum of 10ns hold time as shown in figure 50 and figure 51 . figure 50: mdio output delay figure 51: mdio setup and hold time ta (turn around) the turnaround time is a 2 bit time spacing between the register address field and the data field of the smi frame to avoid contention during a read transac- tion. during a read transaction the phy should not drive mdio in the first bit time and drive ?0? in the second bit time. during a write transaction, the port drives a ?10? pattern to fill the ta time. data (data) the data field is 16 bits long. the phy drives the data field during read trans- actions. the port drives the data field during write transactions. the first data bit transmitted and received shall be bit 15 of the phy register being accessed. idle (idle) the idle condition on mdio is a high impedance state. the mdio driver is disabled and the phy should pull-up the mdio line to a logic one. table 284: bit transmission parts part description 0ns min 300ns max mdc mdio vih min vil max vih min vil max 10ns min mdc mdio 10ns min vih min vil max vih min vil max GT-96100A advanced communication controller revision 1.0 283 12.4.3.1 link detection and link detection bypass (forcelinkpass) typically, the port continuously queries the phy devices for their link status without cpu intervention. the phy addresses used for the link query are determined by the phy_address register and are programmable for each port. the port alternately reads register 1 from the phys and updates the internal link bits according to the value of bit 2 of register 1. in the case of ?link down? (i.e. bit 2 is ?0?), that port will enter link test fail state. in this state, all of the port?s logic is reset. the port exits from link test fail state only when the ?link is up? (i.e. bit 2 of register 1 is read from the port?s phy as ?1?). there is an option to disable the link detection mechanism by forcing the link state of a specific port. this is done by setting port_configuration_extend GT-96100A advanced communication controller 284 revision 1.0 ethernet0 (continued) ethernet0 ip differentiated services codepoint to priority1 low (e0dscp2p1l) 0x84868 page 299 ethernet0 ip differentiated services codepoint to priority1 high (e0dscp2p1h) 0x8486c page 299 ethernet0 vlan priority tag to priority (e0vpt2p) 0x84870 page 299 ethernet0 first rx descriptor pointer 0 (e0frdp0) 0x084880 page 263 ethernet0 first rx descriptor pointer 1 (e0frdp1) 0x084884 ethernet0 first rx descriptor pointer 2 (e0frdp2) 0x084888 ethernet0 first rx descriptor pointer 3 (e0frdp3) 0x08488c ethernet0 current rx descriptor pointer 0 (e0crdp0) 0x0848a0 ethernet0 current rx descriptor pointer 1 (e0crdp1) 0x0848a4 ethernet0 current rx descriptor pointer 2 (e0crdp2) 0x0848a8 ethernet0 current rx descriptor pointer 3 (e0crdp3) 0x0848ac ethernet0 current tx descriptor pointer 0 (e0ctdp0) 0x0848e0 page 255 ethernet0 current tx descriptor pointer 1 (e0ctdp1) 0x0848e4 ethernet0 mib counters 0x085800 - 0x0858ff page 302 ethernet1 ethernet1 port configuration register (e1pcr) 0x088800 page 286 ethernet1 port configuration extend register (e1pcxr) 0x088808 page 288 ethernet1 port command register (e1pcmr) 0x088810 page 291 ethernet1 port status register (e1psr) 0x088818 page 291 ethernet1 serial parameters register (e1spr) 0x088820 page 292 ethernet1 hash table pointer register (e1htpr) 0x088828 page 293 ethernet1 flow control source address low (e1fcsal) 0x088830 page 293 ethernet1 flow control source address high (e1fcsah) 0x088838 page 294 ethernet1 sdma configuration register (e1sdcr) 0x088840 page 294 ethernet1 sdma command register (e1sdcmr) 0x088848 page 295 ethernet1 interrupt cause register (e1icr) 0x088850 page 296 ethernet1 interrupt mask register (e1imr) 0x088858 page 299 table 285: ethernet unit register map (continued) description offset page numbers GT-96100A advanced communication controller revision 1.0 285 ethernet1 (continued) ethernet ip differentiated services codepoint to priority0 low (e0dscp2p0l) 0x88860 page 299 ethernet ip differentiated services codepoint to priority0 high (e0dscp2p0h) 0x88864 page 299 ethernet ip differentiated services codepoint to priority0 low (e0dscp2p1l) 0x88868 page 299 ethernet ip differentiated services codepoint to priority0 high (e0dscp2p1h) 0x8886c page 299 ethernet1 vlan priority tag to priority (e0vpt2p) 0x88870 page 299 ethernet1 first rx descriptor pointer 0 (e1frdp0) 0x088880 page 264 ethernet1 first rx descriptor pointer 1 (e1frdp1) 0x088884 page 266 ethernet1 first rx descriptor pointer 2 (e1frdp2) 0x088888 page 266 ethernet1 first rx descriptor pointer 3 (e1frdp3) 0x08888c page 266 ethernet1 current rx descriptor pointer 0 (e1crdp0) 0x0888a0 ethernet1 current rx descriptor pointer 1 (e1crdp1) 0x0888a4 ethernet1 current rx descriptor pointer 2 (e1crdp2) 0x0888a8 ethernet1 current rx descriptor pointer 3 (e1crdp3) 0x0888ac ethernet1 current tx descriptor pointer 0 (e1ctdp0) 0x0888e0 page 260 ethernet1 current tx descriptor pointer 1 (e1ctdp1) 0x0888e4 page 261 ethernet1 mib counters 0x089800 - 0x0898ff page 302 table 286: phy address register, offset: 0x080800 bits field name function initial value 4:0 phyad0 phy device address for port 0. 00100 9:5 phyad1 phy device address for port 1. 00101 table 285: ethernet unit register map (continued) description offset page numbers GT-96100A advanced communication controller 286 revision 1.0 table 287: smi register (smir), offset: 0x080810 bits field name function initial value 15:0 data ? smi read operation two transactions are required: (1) write to the smi register with opcode = 1, phyad, regad with the data being any value; (2) read from the smi regis- ter. when reading back the smi register, the data is the addressed phy register contents if the read- valid bit (#27) is 1. the data remains undefined as long as readvalid is 0. ? smi write operation one transaction is required. write to the smi regis- ter with opcode = 0, phyad, regad with the data to be written to the addressed phy register. 0 20:16 phyad phy device address 0 25:21 regad phy device register address 0 26 opcode 0 - write 1 - read 1 27 readvalid 1 - indicates that the read operation has been completed for the addressed regad register, and the data is valid on the data field. 0 28 busy 1 - indicates that an operation is in progress and that cpu must not write to the smi register at this time. 0 31:29 n/a these bits must be written as 0 for any write to the smi reg- ister. 0 table 288: port configuration register (pcr), offset: 0x084800 for ethernet_0; 0x088800 for ethernet_1 bits field name function initial value 0 pm promiscuous mode 0 - normal mode. frames are received only if destination address is found in hash table. 1 - promiscuous mode. frames are received regardless of their destination address. errored frames are discarded unless pbf is set. 0 GT-96100A advanced communication controller revision 1.0 287 1 rbm reject broadcast mode 0 - receive broadcast address. 1 - reject frames with broadcast address. overridden by promiscuous mode. 0 2 pbf pass bad frames 0 - normal mode. 1 - pass bad frames. the ethernet receiver will pass to cpu errored frames, which are normally rejected, like fragments and collided packets. frames are passed only if they pass address filtering successfully. 0 6:3 reserved reserved. 0 7 en enable 0 - disabled. 1 - enable. ethernet port is ready to transmit/receive. 0 9:8 lpbk loop back mode 00 - normal mode. 01 - internal loopback mode. tx data is looped back to the rx lines. no transition is seen on the interface pins. 10 - external loopback mode. tx data is looped back to the rx lines and also transmitted out to the mii interface pins. 11 - reserved. 0 10 fc force collision 0 - normal mode. 1 - force collision on any tx frame. for rxm test (in loop- back mode). 0 11 reserved. 0 12 hs hash size 0 - 8k address filtering (256kb of memory space required). 1 - 1/2k address filtering (16kb of memory space required). 0 13 hm hash mode 0 - hash function 0. 1 - hash function 1. 0 14 hdm hash default mode 0 - discard addresses not found in address table. 1 - pass addresses not found in address table. 0 table 288: port configuration register (pcr), offset: 0x084800 for ethernet_0; 0x088800 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller 288 revision 1.0 15 hd duplex mode 0 - half duplex. 1 - full duplex. note: valid only when auto-negotiation for duplex mode is disabled. 0 27:16 reserved 30:28 0x6 isl enabled 0x0 isl disabled note: when isl is enabled, bit 31 must set to 0. 31 accs accelerate slot time 0 - normal mode. 1 - reserved. 0 table 289: port configuration extend register (pcxr), offset: 0x084808 for ethernet_0; 0x088808 for ethernet_1 bits field name function initial value 0 igmp igmp packets capture enable. 0 - igmp packets are treated as normal multicast packets. 1 - igmp packets on ipv4/ipv6 over ethernet/802.3 are trapped and sent to high priority rx queue. 0 1 span spanning tree packets capture enable. 0 - bpdu (bridge protocol data unit) packets are treated as normal multicast packets. 1 - bpdu packets are trapped and sent to high priority rx queue. 0 2 par partition enable. when more than 61 collisions occur while transmitting, the port enters partition mode. it waits for the first good packet from the wire, and then goes back to normal mode. under partition mode it continues transmitting, but it does not receive. 0 - normal mode. 1 - partition mode. 0 table 288: port configuration register (pcr), offset: 0x084800 for ethernet_0; 0x088800 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 289 5:3 priotx priority weight in the round-robin between high and low prior- ity tx queues: 000 - 1 pkt transmitted from high, 1 pkt from low. 001 - 2 pkt transmitted from high, 1 pkt from low. 010 - 4 pkt transmitted from high, 1 pkt from low. 011 - 6 pkt transmitted from high, 1 pkt from low. 100 - 8 pkt transmitted from high, 1 pkt from low. 101 - 10 pkt transmitted from high, 1 pkt from low. 110 - 12 pkt transmitted from high, 1 pkt from low. 111 - all pkt transmitted from high, 0 pkt from low. low will be served only if high is empty. if high queue is emptied before finishing the count, the count will be reset until next first high comes in. 0 7:6 priorx default priority for packets received on this port: 00 - lowest priority. 11 - highest priority. 0 8priorx_ override override priority for packets received on this port: 0 - do not override. 1 - override with GT-96100A advanced communication controller 290 revision 1.0 15:14 mfl max frame length. maximum packet allowed for reception (including crc): 00 - 1518 bytes 01 - 1536 bytes 10 - 2048 bytes 11 - 64k bytes 0 16 mibclrmode mib counters clear mode. setting this bit causes the counters to reset when the cpu performs a counter read operation. in order to reset all mib counters, the cpu should set this bit and read all the counters. 0 17 mibctrmode reserved. 0 18 speed port speed 0 - 10mbit/sec. 1 - 100mbit/sec. note: valid only if speeden bit is set. 0 19 speeden enable auto-negotiation for speed 0 - enable. 1 - disable. 0 20 rmiien rmii enable 0-port mii1 functions as mii port 1 1-port mii1 functions as rmii port 0 and rmii port 1 0 21 dscpen dscp enable 0-ip dscp field decoding is disabled 1-ip dscp field decoding is enabled 0 27:22 reserved reserved. 0 31:28 test these bits must be set to 0 for proper operation of the ether- net port. 0 table 289: port configuration extend register (pcxr), offset: 0x084808 for ethernet_0; 0x088808 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 291 table 290: port command register (pcmr), offset: 0x084810 for ethernet_0; 0x088810 for ethernet_1 bits field name function initial value 14:0 reserved reserved. 0 15 fj force jam / flow control. when in halfduplex, the cpu uses this bit to force collisions on the ethernet segment. when the cpu recognizes that it is going to run out of receive buffers, it can force the trans- mitter to send jam frames, forcing collisions on the wire. the cpu must clear the fj bit when more resources are avail- able in order to allow transmission on the ethernet segment. when in full-duplex and flow-control is enabled, this bit causes the port?s transmitter to send flow-control pause packets. the cpu should reset this bit when more resources are available. 0 31:16 reserved reserved. 0 table 291: port status register (psr), offset: 0x084818 for ethernet_0; 0x088818 for ethernet_1 bits field name function initial value 0 speed indicates port speed. 0 - 10mbit/s. 1 - 100mbit/s. this bit is read-only. 0 1 duplex indicates port duplex mode. 0 - half duplex. 1 - full duplex. this bit is read-only. 0 2 fctl indicates flow-control mode. 0 - flow-control mode enabled. 1 - flow-control mode disabled. this bit is read-only. 0 3 link indicates link status. 0 - link is down. 1 - link is up. this bit is read-only. 0 GT-96100A advanced communication controller 292 revision 1.0 4 pause indicates that the port is in flow-control disabled state. this bit is set when an ieee 802.3x flow-control pause (xoff) packet is received (assuming that flow-control is enabled and the port is in full-duplex mode). reset when xon is received, or when the xoff timer has expired. this bit is read-only. 0 5 txlow tx low priority status. indicates the status of the low priority transmit queue: 0 - stopped. 1 - running. this bit is read-only. 0 6 txhigh tx high priority status. indicates the status of the high priority transmit queue: 0 - stopped. 1 - running. this bit is read-only. 0 7 txinprog tx in progress. indicates that the port?s transmitter is in an active transmission state. this bit is read-only. 0 31:8 reserved reserved. 0 table 292: serial parameters register (spr), offset: 0x084820 for ethernet_0; 0x088820 for ethernet_1 bits field name function initial value 1:0 jam_length two bits to determine the jam length (in backpressure) as follows: 00 = 12k bit-times. 01 = 24k bit-times. 10 = 32k bit-times. 11 = 48k bit-times. 11 (48k bit time) 6:2 jam_ipg five bits to determine the jam ipg. the step is four bit-times. the jam ipg varies between 4 bit time to 124. 01000 (32 bit time) 11:7 ipg_jam_to_ data five bits to determine the ipg jam to data. the step is four bit-times. the value may vary between 4 bit time to 124. 10000 (64 bit time) table 291: port status register (psr), offset: 0x084818 for ethernet_0; 0x088818 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 293 16:12 ipg_data inter-packet gap (ipg): the step is 4 bit-times. the value may vary between 12 bit time to 124. note: these bits may be changed only when all ethernet port is disabled. 11000 (96 bit time) 21:17 data_blind data blinder the number of nibbles from the beginning of the ipg, in which the ipg counter is restarted when detecting a carrier activity. following this value, the port enters the data blinder zone and does not reset the ipg counter. this ensures fair access to the medium. value should be written in hexadecimal format. the default is 0x19 (64 bit time -2/3 of the default ipg). the step is 4bit (nibble) time. valid range is 0xc to 0x1f. note: these bits may be changed only when the ethernet port is disabled. 11001 (64 bit time) 22 limit4 the number of consecutive packet collisions that will occur before the collision counter is reset. 0- the port resets its collision counter after 16 consecutive retransmit trials and restarts the backoff algorithm. 1- the port will reset its collision counter and restart the backoff algorithm after 4 consecutive transmit trials. 0 31:23 reserved reserved 0 table 293: hash table pointer register (htpr), offset: 0x084828 for ethernet_0; 0x088828 for ethernet_1 bits field name function initial value 31:0 htp 32-bit pointer to the address table. bits [2:0] must be set to zero. 0x0 table 294: flow control source address low (fcsal), offset: 0x084830 for ethernet_0; 0x088830 for ethernet_1 bits field name function initial value 15:0 sa[15:0] source address the least significant bits of the source address for the port. this address is used for flow control. 0 table 292: serial parameters register (spr), offset: 0x084820 for ethernet_0; 0x088820 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller 294 revision 1.0 table 295: flow control source address high (fcsah), offset: 0x084838 for ethernet_0; 0x088838 for ethernet_1 bits field name function initial value 31:0 sa[47:16] source address the most significant bits of the source address for the port. this address is used for flow control. 0 table 296: sdma configuration register (sdcr), offset: 0x084840 for ethernet_0; 0x088840 for ethernet_1 bits field name function initial value 1:0 reserved reserved. 0 5:2 rc retransmit count sets the maximum number of retransmits per packet. after executing retransmit for rc times, the tx sdma closes the descriptor with a retransmit limit error indication and pro- cesses the next packet. when rc is set to 0, number of retransmits in unlimited. in this case, retransmit process is terminated only if cpu issues an abort command. 1111 6 blmr big/little endian receive mode the dma supports big or little endian configurations per channel. the blmr bit only affects data transfer to memory. 0 - big endian. 1 - little endian. 1 7 blmt big/little endian transmit mode the dma supports big or little endian configurations per channel. the blmt bit only affects data transfer from mem- ory. 0 - big endian. 1 - little endian. 1 8 povr pci override when set, causes the sdma to direct all its accesses in pci_0 direction and overrides normal address decoding process. 0 9 rifb receive interrupt on frame boundaries when set, the sdma rx generates interrupts only on frame boundaries (i.e. after writing the frame status to the descrip- tor). 0 11:10 reserved reserved. 0 GT-96100A advanced communication controller revision 1.0 295 13:12 bsz burst size sets the maximum burst size for sdma transactions: 00 - burst is limited to 1 64bit words. 01 - burst is limited to 2 64bit words. 10 - burst is limited to 4 64bit words. 11 - burst is limited to 8 64bit words. 0 31:14 reserved reserved. 0 table 297: sdma command register (sdcmr), offset: 0x084848 for ethernet_0; 0x088848 for ethernet_1 bits field name function initial value 6:0 reserved reserved. 0 7 erd enable rx dma. set to ?1? by the cpu to cause the sdma to start a receive process. cleared when the cpu issues an abort receive command. 0 14:8 reserved reserved. 0 15 ar abort receive set to ?1? by the cpu to abort a receive sdma operation. when the ar bit is set, the sdma aborts its current opera- tion and moves to idle. no descriptor is closed. ar bit is cleared upon entering idle. after setting ar bit, the cpu should poll it in order to verify that the abort sequence is completed. 0 16 stdh stop tx high set to ?1? by the cpu to stop the transmission process from the high priority queue at the end of the current frame. an interrupt is generated when the stop command has been executed. writing ?1? to stdh resets txdh bit. writing ?0? to this bit has no effect. 0 17 stdl stop tx low set to ?1? by the cpu in order to stop the transmission pro- cess from the low priority queue at the end of the current frame. an interrupt is generated when the stop command has been executed. writing ?1? to stdl resets txdl bit. writing ?0? to this bit has no effect. 0 table 296: sdma configuration register (sdcr), offset: 0x084840 for ethernet_0; 0x088840 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller 296 revision 1.0 22:18 reserved reserved. 0 23 txdh start tx high set to ?1? by the cpu in order to cause the sdma to fetch the first descriptor and start a transmit process from the high priority tx queue. writing ?1? to txdh resets stdh bit. writing ?0? to this bit has no effect. 0 24 txdl start tx low set to ?1? by the cpu to cause the sdma to fetch the first descriptor and start a transmit process from the low priority tx queue. writing ?1? to txdl resets stdl bit. writing ?0? to this bit has no effect. 0 30:25 reserved reserved. 0 31 at abort transmit set to ?1? by the cpu to abort a transmit dma operation. when the at bit is set, the sdma aborts its current opera- tion and moves to idle. no descriptor is closed. cleared upon entering idle. after setting at bit, the cpu must poll it in order to verify that the abort sequence is completed. 0 table 298: interrupt cause register (icr), offset: 0x084850 for ethernet_0; 0x088850 for ethernet_1 bits field name function initial value 0 rxbuffer rx buffer return indicates a rx buffer returned to cpu ownership or that the port finished reception of a rx frame in either priority queues. note: in order to get a rx buffer return per priority queue, use bit 19:16. this bit is set upon closing any rx descriptor which has its ei bit set. in order to limit the interrupts to frame (rather than buffer) bound- aries, the user should set sdcr GT-96100A advanced communication controller revision 1.0 297 2 txbufferhigh tx buffer for high priority queue indicates a tx buffer returned to cpu ownership or that the port finished transmission of a tx frame. note: this bit is set upon closing any tx descriptor which has its ei bit set. in order to limit the interrupts to frame (rather than buffer) boundaries, the user should set ei only in the last descriptor. 0 3 txbufferlow tx buffer for low priority queue indicates a tx buffer returned to cpu ownership or that the port finished transmission of a tx frame. note: this bit is set upon closing any tx descriptor which has its ei bit set. in order to limit the interrupts to frame (rather than buffer) boundaries, the user should set ei only in the last descriptor. 0 5:4 reserved reserved. 0 6 txendhigh tx end for high priority queue indicates that the tx dma stopped processing the high prior- ity queue after stop command, or that it reached the end of the high priority descriptor chain. 0 7 txendlow tx end for low priority queue indicates that the tx dma stopped processing the low prior- ity queue after stop command, or that it reached the end of the low priority descriptor chain. 0 8 rxerror rx resource error indicates a rx resource error event in either priority queues. note: in order to get a rx resource error indication per priority queue, use bit 23:20. event 0 9 reserved reserved. 0 10 txerrorhigh tx resource error for high priority queue indicates a tx resource error event during packet transmis- sion from the high priority queue. 0 11 txerrorlow tx resource error for low priority queue indicates a tx resource error event during packet transmis- sion from the low priority queue. 0 12 rxovr rx overrun indicates an overrun event that occured during reception of a packet. 0 13 txudr tx underrun indicates an underrun event that occured during transmis- sion of packet from either queue. 0 table 298: interrupt cause register (icr), offset: 0x084850 for ethernet_0; 0x088850 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller 298 revision 1.0 16 rxbuffer- queue[0] rx buffer return in priority queue[0], indicates a rx buffer returned to cpu ownership or that the port completed recep- tion of a rx frame in a receive priority queue[0] 0 17 rxbuffer- queue[1] rx buffer return in priority queue[1], indicates a rx buffer returned to cpu ownership or that the port completed recep- tion of a rx frame in a receive priority queue[1] 0 18 rxbuffer- queue[2] rx buffer return in priority queue[2], indicates a rx buffer returned to cpu ownership or that the port completed recep- tion of a rx frame in a receive priority queue[2] 0 19 rxbuffer- queue[3] rx buffer return in priority queue[3], indicates a rx buffer returned to cpu ownership or that the port completed recep- tion of a rx frame in a receive priority queue[3] 0 20 rxerror- queue[0] rx resource error in priority queue[0], indicates a rx resource error event in receive priority queue[0] 0 21 rxerror- queue[1] rx resource error in priority queue[1], indicates a rx resource error event in receive priority queue[1] 0 22 rxerror- queue[2] rx resource error in priority queue[2], indicates a rx resource error event in receive priority queue[2] 0 23 rxerror- queue[3] rx resource error in priority queue[3], indicates a rx resource error event in receive priority queue[3] 0 27:24 reserved reserved. 0 28 miiphystc mii phy status change indicates a status change reported by the phy connected to this port. set when the mii management interface block identifies a change in phy?s register 1. 0 29 smidone smi command done indicates the smi completed a mii management command (either read or write) that was initiated by the cpu writing to the smi register. 0 30 reserved reserved. 0 31 etherintsum ethernet interrupt summary this bit is a logical or of the (unmasked) bits [30:4] in the interrupt cause register. 0 table 298: interrupt cause register (icr), offset: 0x084850 for ethernet_0; 0x088850 for ethernet_1 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 299 table 299: interrupt mask register (imr), offset: 0x084858 for ethernet_0; 0x088858 for ethernet_1 bits field name function initial value 31:0 various mask bits for interrupt cause register. 0x0 table 300: ip differentiated services codepoint to priority0 low (dscp2p0l) bits field name function initial value 31:0 priority0 low the lsb priority bit for dscp[31:0] entries. 0x0 table 301: ip differentiated services codepoint to priority0 high (dscp2p0h) bits field name function initial value 31:0 priority0 high these bits are the lsb priority bit for dscp[63:32] entries. 0x0 table 302: ip differentiated services codepoint to priority1 low (dscp2p1l) bits field name function initial value 31:0 priority1 low these bits are the msb priority bit for dscp[31:0] entries. 0x0 table 303: ip differentiated services codepoint to priority1 high (dscp2p1h) bits field name function initial value 31:0 priority1 high these bits are the msb priority bit for dscp[63:32] entries. 0x0 table 304: vlan priority tag to priority (vpt2p) bits field name function initial value initial value 7:0 priority0 these bits are the lsb priority bit for vlan priority[7:0] entries. 0xcc 15:8 priority1 these bits are the msb priority bit for vlan priority[7:0] entries. 0xf0 31:16 reserved. 0x0 GT-96100A advanced communication controller 300 revision 1.0 12.5.1 defining a priority queue to the ip dscp or vlan entry to define a priority queue to the ip dscp or vlan entry, the entry's priority 0 and priority 1 bits must be defined. table 305 and table 306 describe the writing of ip dscp and vlan entries respectively for a few set exam- ples. table 307 describes three example cases for mixed priority queueing. table 305: writing ip dscp priority example ip dscp value priority msb bit priority lsb bit 0 dscp2p1l[0] dscp2p0l[0] 16 dscp2p1l[16] dscp2p0l[16] 31 dscp2p1l[31] dscp2p0l[31] 32 dscp2p1h[0] dscp2p0h[0] 48 dscp2p1h[16] dscp2p0h[16] 63 dscp2p1h[31] dscp2p0h[31] table 306: writing vlan priority example vlan priority value priority msb bit priority lsb bit 0 vpt2p[8] vpt2p[0] 4 vpt2p[12] vpt2p[4] 7 vpt2p[15] vpt2p[7] GT-96100A advanced communication controller revision 1.0 301 12.6 ethernet mib counters the ethernet unit includes a set of counters that are used to count events occurring on the segment to which the port is connected to. all counters are 32 bit wide. the cpu must read all the mib counters during initialization in order to reset the counters to ?0?. the counters will only be reset to ?0? if mibclrmode bit in the port_configuration_extend register is set to ?0? (default). if mibclrmode bit is ?1?, reading the mib counters will have no effect on their value. note: table 309 lists definitions of terms used in the counter descriptions. table 307: writing ip dscp and vlan priority example case ipdscp all others vlan tag packets a 0x0 and 0x3f (63) directed to pri- ority queue 3 directed to priority queue 0 ignored b <0x20 (32) directed to priority queue 2 directed to priority queue 1 directed to priority queue 3 c 0x1f (31) and 0x20 (32) directed to priority queue 3 0x0 and 0x3f (63)directed to pri- ority queue 0<0x1f (31) directed to priority queue 1 directed to priority queue 2 >3 and ip dscp 0x1f or 0x20 directed to priority queue 2 other tags are ignored table 308: writing ip dscp and vlan priority register mapping example register case a case b case c dscpc2p0l 0x00000001 0x00000000 0xfffffffe dscp2p0h 0x80000000 0xffffffff 0x00000001 dscp2p1l 0x00000001 0xffffffff 0x80000000 dscp2p1h 0x80000000 0x00000000 0x7fffffff vpt2p 0x00000001 0x0000ffff 0x0000f000 table 309: terms used in mib counters descriptions term definition packet data section all data bytes in the packet following the sfd until the end of the packet. packet data length the number of data bytes in the packet data section. data octet a single byte from the packet data section. nibble 4 bits (half byte) of a data octet. misaligned packet a packet with an odd number of nibbles. GT-96100A advanced communication controller 302 revision 1.0 received good packet a received packet which is well formed. received bad packet a received packet which has an error such as bad crc, rx error event, invalid size (too short or too long). transmitted packet any transmitted packet (not including collision fragments). collision event any collision event that is indicated by assertion of mii_col signal within the col- lision window interval. late collision event any collision event that is indicated by assertion of mii_col signal outside the collision window interval. rx error event an error event that is indicated by assertion of mii_rx_err signal. dropped packet a received packet which is dropped by the port due to lack of resources (e.g. no rx buffers available). mibctrmode mibctrmode bit in the port configuration extend register. maxframesize 1518, 1536, 2 k or 64kbytes depending on the setting in the port configuration extend register. table 310: ethernet mib counters, offset: 0x085800?0x0858ff for ethernet_0; 0x089800?0x0898ff for ethernet_1 address for port 0 address for port 1 counter name function initial value 0x085800 0x089800 bytes received this counter increments once for every data octet of good packets (unicast + multicast + broadcast) received by the port. - 0x085804 0x089804 bytes sent this counter increments once for every data octet of transmitted packets sent by the port. - 0x085808 0x089808 frames received this counter increments once for every good packet (unicast + multicast + broadcast) received by the port. - 0x08580c 0x08980c frames sent this counter increments once for every transmitted packet sent by the port. - table 309: terms used in mib counters descriptions (continued) term definition GT-96100A advanced communication controller revision 1.0 303 0x085810 0x089810 total bytes received this counter increments once for every data octet of all received packets. this includes data octets of bad packets, which might be automatically rejected by the port (e.g fragments). this counter reflects all the data octets received from the line. note: a nibble is not counted as a whole byte. - 0x085814 0x089814 total frames received this counter increments once for every received packet. this includes bad packets. this counter reflects all pack- ets received from the line. - 0x085818 0x089818 broadcast frames received this counter increments once for every good broadcast packet received. - 0x08581c 0x08981c multicast frames received this counter increments once for every good multicast packet received. this counter does not count broadcast packets. - 0x085820 0x089820 crc error this counter increments once for every received packet which meets all the fol- lowing conditions (i.e. logical and of the following conditions): ? packet data length is between 64 and maxframesize bytes inclusive (i.e. valid packet data length per ieee std). ? packet has invalid crc. ? collision event has not been detected. ? late collision event has not been detected. ? rx error event has not been detected. - table 310: ethernet mib counters, offset: 0x085800?0x0858ff for ethernet_0; 0x089800?0x0898ff for ethernet_1 (continued) address for port 0 address for port 1 counter name function initial value GT-96100A advanced communication controller 304 revision 1.0 0x085824 0x089824 oversize frames this counter increments once for every received packet which meets all the fol- lowing conditions (i.e. logical and of the following conditions): ? packet data length is greater than maxframesize. ? packet has valid crc. ? rx error event has not been detected. - 0x085828 0x089828 fragments this counter increments once for every received packet which meets all the fol- lowing conditions (i.e. logical and of the following conditions): ? packet data length is less than 64 bytes -or- packet without sfd and is less than 64 bytes in length. ? collision event has not been detected. ? late collision event has not been detected. ? rx error event has not been detected. ? packet has invalid crc. - 0x08582c 0x08982c jabber this counter increments once for every received packet which meets all the fol- lowing conditions (i.e. logical and of the following conditions): ? packet data length is greater than maxframesize. ? packet has invalid crc. ? rx error event has not been detected. - 0x085830 0x089830 collision this counter increments once for every received packet which meets both of the following conditions (i.e. logical and of the following conditions): ? collision event has been detected. ? rx error event has not been detected. - table 310: ethernet mib counters, offset: 0x085800?0x0858ff for ethernet_0; 0x089800?0x0898ff for ethernet_1 (continued) address for port 0 address for port 1 counter name function initial value GT-96100A advanced communication controller revision 1.0 305 0x085834 0x089834 late collision this counter increments once for every received packet which meets both of the following conditions (i.e. logical and of the following conditions): ? late collision event has been detected. ? rx error event has not been detected. - 0x085838 0x089838 frames 64 bytes this counter increments once for every received and transmitted packet with size of 64 bytes. this counter does not count bad received packets. - 0x08583c 0x08983c frames 65-127 bytes this counter increments once for every received and transmitted packet with size of 65 to 127 bytes. this counter does not count bad received packets. - 0x085840 0x089840 frames 128-255 bytes this counter increments once for every received and transmitted packet with size of 128 to 255 bytes. this counter does not count bad received packets. - 0x085844 0x089844 frames 256-511 bytes this counter increments once for every received and transmitted packet with size of 256-511 bytes. this counter does not count bad received packets. - 0x085848 0x089848 frames 512-1023 bytes this counter increments once for every received and transmitted packet with size of 512-1023 bytes. this counter does not count bad received packets. - 0x08584c 0x08984c frames 1024- maxframesize bytes this counter increments once for every received and transmitted packet with size of 1024 to maxframesize bytes. this counter does not count bad received packets. - 0x085850 0x089850 rx error this counter increments once for every received packet in which the rx error event has been detected. when a rx error event occurs, the following counters do not increment: crc error, oversize frames, fragments, jabbers, collision and late collision. - 0x085854 0x089854 dropped frames reserved. - table 310: ethernet mib counters, offset: 0x085800?0x0858ff for ethernet_0; 0x089800?0x0898ff for ethernet_1 (continued) address for port 0 address for port 1 counter name function initial value GT-96100A advanced communication controller 306 revision 1.0 0x085858 0x089858 out multicast frames the number of multicast frames sent by the port. this counter does not count broadcast packets. - 0x08585c 0x08985c out broadcast frames the number of broadcast frames sent by the port. - out unicast frames calculated from: ? "frames sent" ? "out multicast frames" ? "out broadcast frames" 0x085860 0x089860 undersize frames this counter increments once for every received packet which meets all the fol- lowing conditions (i.e. logical and of the following conditions): ? packet data length is less than 64 bytes. ? collision event has not been detected. ? late collision event has not been detected. ? rx error event has not been detected. ? packet has valid crc. - table 310: ethernet mib counters, offset: 0x085800?0x0858ff for ethernet_0; 0x089800?0x0898ff for ethernet_1 (continued) address for port 0 address for port 1 counter name function initial value GT-96100A advanced communication controller revision 1.0 307 13. s erial dma (sdma) 13.1 overview there are 16 sdma channels on the GT-96100A that are dedicated for moving data between the serial communi- cations channels (mpscs) and memory buffers. each sdma channel consists of a dma engine for receiving and one for transmitting. the 16 sdma channels are logically divided in two identical groups. each group consists of 8 sdma channels - one sdma channel per mpsc. in both groups sdma channel 0 is allocated to data transfer from/to mpsc0, sdma1 is tied to mpsc1 and so on. each mpsc can be programmed to use a specific sdma channel from one of the groups, making it possible to split the serial data flow into two logical streams. these streams can be assigned a different priority tag at the ciu level. each sdma channel has two dedicated fifos for data buffering (for a total of 32 fifos). all fifos are 256 bytes deep. for receive operations, the mpsc moves received data into the dedicated fifo of the corresponding sdma. then, using descriptors set up by the user, the sdma moves the data into memory buffers. for transmit opera- tions, the sdma uses descriptors set up by the user to move data out of buffers into the dedicated fifo. the mpsc moves the data down to the serial communications link. the sdma channel descriptors use a chained data structure. they work without cpu interference after appro- priate initialization. sdma channels can be programed to generate interrupts on buffer or frame boundaries. when enabled, he receive sdmas run freely and expect to find a valid descriptor, when one is required. when a receive sdma channel accesses an invalid descriptor, the receive sdma process halts with a resource error sta- tus indication. when enabled, the transmit sdmas run freely until the end of the descriptor chain is reached. when a transmit sdma accesses an invalid descriptor and the last descriptor was not marked as an end of frame descriptor, the transmit sdma process halts with resource error status indication. the sdmas in each group arbitrate for accessing the descriptors and buffers. a standard round-robin scheme is used for arbitration within the group. the arbitration between the groups is done at the ciu level, which supports a programmable, weighted round-robin algorithm. sdma buffers and descriptor reside either in sdram space or in pci space. address decoding is automatic and does not require user intervention. however, the user may choose to override the address decoding and force one (or more) of the sdmas to direct all its accesses to the pci. GT-96100A advanced communication controller 308 revision 1.0 13.2 sdma descriptors all sdma data transfers are done via a chained link of descriptors. the following rules must be followed when using the GT-96100A sdma descriptors: ? descriptor length is 4lw and it must be 4lw aligned (i.e. descriptor_address[3:0]=0000). ? descriptors may reside anywhere in cpu address space except null address, which is used to indicate end of descriptor chain. ? in normal mode (hdlc and transparent) rx buffers associated with rx descriptors must be 64-bit aligned. minimum size for rx buffers is 8 bytes. in low latency, or byte, mode (bisync, uart, and transparent) rx buffers have no alignment restrictions. ? tx buffers associated with tx descriptors can start in any byte location. ? sdma rx and tx buffers are limited to 64kbytes. figure 52: sdma descriptor format 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 command / status buffer pointer rx descriptor +0 +4 +8 tx descriptor = reserved next descriptor pointer byte count buffer size +c 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 command / status buffer pointer +0 +4 +8 next descriptor pointer shadow byte count +c 0 0 0 0 0 0 0 0 byte count 0 0 = any value in byte mode offset 0 0 0 0 GT-96100A advanced communication controller revision 1.0 309 table 311 through table 315 provide detailed information about the descriptor fields. table 311: sdma descriptor - command/status word bits field name function 31:0 command/sta- tus contains commands bits that instruct the sdma how to process a buffer and sta- tus bits that the sdma updates upon closing a descriptor. the cpu uses the sta- tus bits to evaluate the buffer status. except for bits 31, 30, 23, 17, and 16, the definition of the bits vary depending on which mode is being used. see: ? section 14.5.2 ?sdmax command/status field for hdlc mode? on page 338 . ? section 14.6.3 ?sdmax command/status field for bisync mode? on page 350 . ? section 14.7.2 ?sdmax command/status field for uart mode? on page 362 . ? section 14.8.1 ?sdmax command/status field for transparent mode? on page 374 . 31 o owner bit when set to?1?, the buffer can be processed by the GT-96100A. when set to ?0?, the buffer can be processed by the cpu. an sdma process will halt when a descriptor with owner bit set to ?0? is fetched. 30 am auto mode when set, the sdma won?t clear the owner bit of the descriptor at the end of buffer processing. 29:24 reserved determined by the mode selected. 23 ei enable interrupt the GT-96100A generates a maskable interrupt when closing descriptor with ei bit set. note: if the rifb bit is set in the sdma configuration register, a rx interrupt is generated only if this is the last descriptor associated with a received frame. in this case, ei bit setting is masked for intermediate descriptors. 22:18 determined by the mode selected. 17 f first bit indicates first buffer of a frame. 16 l last bit indicates last buffer of a frame. 15:0 determined by the mode selected. GT-96100A advanced communication controller 310 revision 1.0 table 312: sdma descriptor - buffer size, byte count (rx descriptor) bits field name function 31:16 buffer size the buffer size field is valid only in receive descriptors and is reserved in transmit descriptors.the field is written by the cpu and read by the GT-96100A. when the buffer byte counter of a sdma receive channel reaches the buffer size value, the sdma will close the buffer descriptor and will move to the next buffer. buffer size must be a multiple of 8 when the mpsc is programmed to work in nor- mal mode (hdlc and transparent). buffer size can be arbitrary when working in low bandwidth mode (bisync, uart, and transparent). 15:0 byte count the number of bytes that were actually written by the sdma into the buffer. this number is never greater than buffer size. the cpu must initialize the byte count field with 0x0000. table 313: sdma descriptor - byte count, shadow byte count (tx descriptor) bits field name function 31:16 byte count byte count is the number of bytes to be transmitted. zero byte counters are not supported with retransmission. do not use zero byte buffers with lap-d protocol. 15:0 shadow byte count the cpu must initialize this field with a value identical to the byte count field. the GT-96100A subtracts the number of bytes actually transmitted from this parame- ter. usually the GT-96100A writes ?0? in this field when closing a descriptor. however, when the transmit sdma halts due to a transmit error, this number can be used to determine the number of bytes that were fetched into the GT-96100A. setting both the byte count and shadow byte count to ?0? will cause the sdma to close the descriptor and move to the next descriptor, if both or neither of the f and l bits are set. setting byte count and buffer size to ?0? in transmit descriptors with one of the f or l bits set will lead to unpredictable behavior. table 314: sdma descriptor - buffer pointer bits field name function 31:0 buffer pointer 32-bit pointer to the beginning of the buffer associated with the descriptor. the buffer can reside anywhere in memory or pci address space. GT-96100A advanced communication controller revision 1.0 311 13.3 sdma configuration register (sdc) each sdma has a dedicated configuration register (sdcx). the sdc must be initialized before enabling the sdma channel. figure 53: sdmax configuration register (sdcx) table 315: sdma descriptor - next descriptor pointer bits field name function 31:4 next descriptor pointer 32-bit next descriptor pointer to the beginning of the next descriptor in the chain. a descriptor can reside anywhere in memory or pci space. bits [3:0] must be set to?0?. dma operation is stopped when a null value in the next descriptor pointer is encountered. 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 rft sfm blmr rc povr blmt bsz rifb GT-96100A advanced communication controller 312 revision 1.0 table 316: sdma configuration register (sdcx), offset: 0x000900 bits field name function initial value 0 rft receive fifo threshold ? 0 - 8 bytes ? 1 - half fifo (128 bytes) notes: when working with an 8-bit data path, the threshold is always one byte regardless of the rft value. it is recommended that rft bit be set to ?0? in this case. when rft is set to ?0?, the sdma will not burst. it will transfer one word (64 bits) on each transfer. 0 1 sfm single frame mode ? 0 - multi frame mode. the GT-96100A will read as many frames as needed into the fifo in order to keep the transmit fifo full. the fifo can handle more than one frame at a time. ? 1 - single frame mode. the first descriptor will not be fetched before the current frame?s last descriptor is closed. notes: the sfm bit must be set to ?1? for hdlc collision mode, bisync and uart protocols. when the sfm bit is set to ?0?, cts lost cannot be reported in the correct descriptor/frame. in lan hdlc mode sfm must be set for proper operation. 0 5:2 rc retransmit count in collision modes (lap-d), after executing a backoff proce- dure rc times, the tx sdma will close the buffer with a retransmit limit (rl) error, a maskable interrupt will be gen- erated, and the sdma will go to off state. a new transmit demand command should be issued in order to start a new transmission process. when rc field is 0000, the GT-96100A will try to retransmit forever. the cpu needs to issue an abort command in order to stop the retransmit process. 1111 6 blmr rx big little/endian receive mode the GT-96100A supports big or little endian configuration per channel for maximum system flexibility. the blmr bit only affects data movements. ? 0 - big endian convention. ? 1 - little endian convention 1 GT-96100A advanced communication controller revision 1.0 313 13.4 sdma command register (sdcmx) each sdma has a dedicated sdma command register (sdcmx) register to control its dma process. figure 54: sdma command register (sdcmx) 7 blmt tx big/little endian transmit mode the GT-96100A supports big or little endian configuration per channel for maximum system flexibility. the blmt bit only affects data movements. 1 ? 0 - big endian convention. ? 1 - little endian convention. 1 8 povr pci override when set, causes the sdma to direct all its accesses in pci_0 direction, overriding normal address decoding pro- cess. 0 9 rifb receive interrupt on frame boundaries when set, the sdma rx generates interrupts only on frame boundaries (i.e. after writing the frame status to the descrip- tor). 0 11:10 reserved reserved. 0 13:12 bsz burst size sets the maximum burst size for sdma transactions: ? 00 - burst is limited to 1 64bit words. ? 01 - burst is limited to 2 64bit words. ? 10 - burst is limited to 4 64bit words. ? 11 - burst is limited to 8 64bit words. 0 31:14 reserved. 0 1. the user can define the sdma descriptors as big or little endian through the ciu configuration register. table 316: sdma configuration register (sdcx), offset: 0x000900 (continued) bits field name function initial value 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 erd txd ar at std GT-96100A advanced communication controller 314 revision 1.0 table 317: sdma command register (sdcmx), offset: 0x000908 bits field name function initial value 6:0 reserved reserved. 0 7 erd enable rx dma when set to ?1?, the rx sdma will fetch the 1st descriptor and will be ready for a receive frame. the GT-96100A clears erd when the GT-96100A receive sdma has a resource error or when the cpu issues an abort command. 0 14:8 reserved reserved. 0 15 ar abort receive the cpu sets the ar bit when it needs to abort a receive sdma channel operation. when the ar bit is set, the sdma aborts its operation and goes to idle state. no descriptor is closed. the GT-96100A clears both the ar and erd bits when entering idle state. the cpu must poll bit 15. when it is ?0?, the GT-96100A has completed the abort sequence. after an abort the cpu should write the 1st descriptor address and then set erd bit to ?1?. 0 16 std stop tx the sdma stops transmission at the end of frame (i.e. at the end of buffer with l bit set to ?1?). after transmitting the last buffer, the transmit sdma goes to idle state. the gt- 96100a clears the txd bit when entering idle state. after the sdma stops, the cpu must write the first descriptor address and than set the txd bit to ?1?. the GT-96100A sig- nals the cpu with interrupt when the stop procedure is accomplished. 0 22:17 reserved reserved. 0 23 txd tx demand when this bit is set to ?1?, the tx dma will fetch the first descriptor and will start the transmission process. the gt- 96100a clears txd when it successfully ends an sdma transmit process. it also clears txd when a resource error occurs, when the transmit process is halted due to channel error (i.e. cts# lost), or when the cpu issues an abort com- mand. 0 30:24 reserved reserved 0 GT-96100A advanced communication controller revision 1.0 315 13.5 sdma group configuration register use this register to assign a specific sdma channel from one of the sdma groups to handle the data stream associated with the corresponding mpsc. note: mpsc?s receive and transmit data flows does not have to be assigned to the same sdma group. for example, there is no problem with assigning mpsc0 transmit to sdma channel 0 of group 0, while mpsc0 receive flow is handled by sdma channel 0 of group 1. moreover, for certain asymmetric pro- tocols, like adsl, the bandwidth requirements for rx and tx are different, and splitting the data streams between the sdma groups may be critical for controlling bandwidth allocation. 31 at abort transmit the cpu sets the at bit to ?1? when it needs to abort a trans- mit sdma channel operation. when the at bit is set, the sdma aborts its operation and goes to idle state. no descriptor is closed. the GT-96100A clears both the at and txd bits when entering idle state. the cpu must poll bit 31. when it is ?0?, the GT-96100A has completed the abort sequence. after an abort, the cpu must write the first descriptor address and than set txd bit to ?1?. 0 table 318: sdma group register (sgc), offset: 0x101af0 bits field name function initial value 7:0 rxsg[7:0] rx group these bits are used to assign one of the sdma groups to the rx data of each mpsc. rxsg[0] controls mpsc0, rxsg[1] controls mpsc1 and so on. ? 0 - receive data from the mpsc is handled by sdma group 0. ? 1 - receive data from the mpsc is handled by sdma group 1. 0 15:8 txsg[7:0] tx sdma group these bits are used to assign one of the sdma groups to the tx data of each mpsc. txsg[0] controls mpsc0, txsg[1] controls mpsc1 and so on. ? 0 - transmit data to the mpsc is handled by sdma group 0. ? 1 - transmit data to the mpsc is handled by sdma group 1. 0 31:16 reserved reserved. 0 table 317: sdma command register (sdcmx), offset: 0x000908 (continued) bits field name function initial value GT-96100A advanced communication controller 316 revision 1.0 13.6 sdma descriptor pointer registers each sdma channel has three 32-bit registers that reside in a special descriptor?s dual port memory located in the internal address space of the GT-96100A. figure 55: sdma descriptor pointer registers 13.6.1 sdma current receive descriptor pointer (scrdp) scrdpx points to the current receive descriptor in memory. the cpu must write this register with the first descriptor address before enabling the sdma receive channel. when a sdma receive channel is enabled it will fetch the first descriptor pointed to by scrdpx as part of its sdma starting procedure. 13.6.2 sdma current transmit descriptor pointer (sctdp) sctdpx points to the current transmit descriptor in memory. the cpu must write this register with the first descriptor address before enabling the sdma transmit channel. when a sdma transmit channel is enabled it will fetch the first descriptor pointed to by scrdpx as part of its sdma starting procedure. 13.6.3 sdma first transmit descriptor pointer (sftdp) sftdpx points to the first descriptor in a transmit frame. the cpu must write this register with the first descrip- tor address before enabling the sdma transmit channel. the sdma transmit controller uses the sftdp when it needs to restart a transmission after collision (hdlc mode only). the GT-96100A updates the content of sftdp each time it fetches a descriptor with the f (first) bit set to ?1?. note: the cpu must write the same value to both sctdp and sftdp before enabling the corresponding sdma transmit channel. 13.7 transmit sdma 13.7.1 transmit sdma definitions ? sof (start of frame descriptor): descriptor with f (first) bit set to ?1?. ? eof (end of frame descriptor): descriptor with l (last) bit set to ?1?. f and l bits are set by the cpu before releasing a descriptor to the GT-96100A for transmission. 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 098 7654 3210 sdmax current receive descriptor pointer (scrdpx) sdmax first transmit descriptor pointer (sftdpx) sdmax current transmit descriptor pointer (sctdpx) GT-96100A advanced communication controller revision 1.0 317 a frame starts with a sof descriptor and ends with a eof descriptor. a frame can consist of one buffer or split over many buffers. if a frame is stored in one buffer, the associated descriptor will have both the f and l bits set to ?1?. in a non-frame oriented protocol (e.g. bisync or uart), it is recommended that both f and l bits be set to ?1? for each buffer. 13.7.2 transmit sdma flow the following steps are executed during a normal transmit sdma process: 1. before enabling a sdma tx channel the cpu must prepare a valid descriptor with the owner bit set to ?1?. 2. the cpu must then write the first descriptor address to both sctdp and sftdp registers. 3. the cpu issues a transmit demand command. the sdma controller will then fetch the first descriptor and will start the sdma process. 4. when buffer transmission is completed, the sdma will close the buffer descriptor by setting the correct transmit status and writing ?0? in the owner bit, returning the buffer to the cpu. 13.7.3 retransmit in hdlc (lap-d) mode when working in collision mode (see mpsc section), the GT-96100A retransmits if collision occurs before the sdma fetches the 3rd descriptor. if the frame consists of more than two buffers, the user must assure that there is enough data in the first two buffers to compensate for this behavior. the GT-96100A can buffer up to 256 bytes in its internal tx fifo. this should be considered when preparing a lap-d transmit frame. 13.7.4 transmit sdma notes the transmit sdma process is frame oriented . the transmit sdma does not clear the frame?s first descriptor ownership bit until the last descriptor associated with this frame is closed. the transmit sdma then writes ?0? to the first descriptor owner bit and generate an interrupt if the ei bit of the first descriptor is set. the transmit sdma stops the dma process whenever it reaches a descriptor with null (0x00000000) value in the nextdescriptorpointer (ndp) field or when it fetches a descriptor with owner bit set to ?0?. when the transmit sdma controller encouters a null ndp value or a not-owned descriptor with it's first field bit set, after the last descriptor of a frame, the transmit idles. the txd bit is cleared and the transmit sdma controller return to idle state. when the transmit sdma controller encouter a null ndp value, or a not-owned descriptor with it's first field bit set, in the middle of a frame or a not-owned descriptor with it's first field bit reset, after the last descrip- tor of a frame, the transmit aborts. the txd bit is cleared, a tx resource error maskable interrupt is gen- erated and the transmit sdma controller return to idle state. when the transmit sdma controller encouters a not-owned descriptor with it's first field bit reset, in the mid- dle of a frame, the transmit stops. the txd bit is not cleared and the transmit sdma controller waits for an abort transmit command. in such cases, the sdma controller clears the txd bit before returning to idle state. in normal operation, the transmit sdma never expects to find a null nextdescriptorpointer or not-owned descriptor in the middle of a frame. when this occurs, the transmit sdma controller aborts, the txd bit is cleared and a tx resource error maskable interrupt is generated. GT-96100A advanced communication controller 318 revision 1.0 note: in collision mode, if a collision occurs exactly one clock cycle after a resource error, the GT-96100A ignores the resource error and retransmit the frame. when the cpu needs to interfere with the transmit process without corrupting the ongoing transmit process, it can issue a stop command by writing ?1? to the std bit in the sdma command register. the transmit sdma controller stops after completing the transmission of the active frame. when issuing an std command txd is reset to ?0? upon entering idle state. the cpu can then issue a new transmit demand command to restart the sdma process. 13.8 receive sdma 13.8.1 receive sdma definitions f and l bits are set by the cpu before releasing a descriptor to the GT-96100A. a frame starts with an sof descriptor and ends with an eof descriptor. a frame can be contained in one buffer or split over many buffers. if a frame is stored in one buffer, the associated descriptor will have both f and l bits set to ?1?. 13.8.2 receive sdma flow the following steps are executed during a normal transmit sdma process: 1. before enabling a sdma rx channel the cpu must prepare a valid descriptor with the owner bit set to ?1?. 2. the cpu must then write the descriptor address to the scrdp register before enabling the receive sdma channel. 3. the cpu writes ?1? to the erd bit in the sdcm register, enabling the receive sdma channel. 4. normally the receive sdma controller will then run continuously, processing received data from the mpsc. notes: the receive sdma controller never expects to encounter a descriptor with owner bit set to ?0? or a null value (0x00000000) in the ndp field. if this occurs, the receive sdma aborts and a maskable rx resource error interrupt is generated. use the receive abort command for the cpu to stop the receive sdma. it is the cpu?s responsibility to properly restart the descriptor chain. table 319: sdma definitions term definition sof start of frame descriptor descriptor with f (first) bit set to ?1?. eof end of frame descriptor descriptor with l (last) bit set to ?1?. GT-96100A advanced communication controller revision 1.0 319 13.9 sdma interrupt and mask register (sdi and sdm) each sdma channel has two maskable interrupt sources. one is for resource error events and the other one is for descriptor closed events. 13.9.1 resource error interrupt when a receive sdma encounters a null descriptor pointer or a not owned descriptor, a resource error inter- rupt is generated. a resource error interrupt is generated whenever a transmit sdma encounters a null descriptor pointer or a not-owned descriptor in a middle of a frame. note: when the GT-96100A encounters a descriptor with owner bit set to 0, it still expects to find that all the other fields of the descriptor are legitimate. a descriptor with owner bit set to 0, with non-legitimate fields (such as start of frame descriptor with f (first) bit not set to ?1?) can lead to unpredictable behavior. 13.9.2 descriptor/frame closed interrupt when a sdma channel closes a descriptor with the ei (enable interrupt) bit set to ?1?, a descriptor closed inter- rupt is generated. notes: in case the rifb bit is set in the sdma configuration register, an interrupt is generated by the rx chan- nel only on receive frame boundaries. the correct operation of the frame level interrupt requires all rx descriptors to have their ei bit set. 13.10 sdma in auto mode the cpu can set bit 30 in the command/status field of transmit or receive descriptors directing the GT-96100A to work in auto mode. when working with an auto mode descriptor, the GT-96100A sdma works as usual except that it does not clear the ownership bit when closing the descriptor. the cpu can use this for example to cause the GT-96100A to transmit endlessly (until cpu intervention). GT-96100A advanced communication controller 320 revision 1.0 figure 56: using auto mode to create idle loop 13.11 sdma registers table 320: sdma group 0 register map description offset page number sdma group configuration register 0x101af0 page 315 channel0 channel0 configuration register (s0dc0) 0x000 9 00 page 312 channel0 command register (s0dcm0) 0x000 9 08 page 314 channel0 rx descriptor 0x008 9 00 - 0x008 9 0f not to be accessed dur- ing normal operation. channel0 current rx descriptor pointer (s0crdp0) 0x008 9 10 page 316 channel0 tx descriptor 0x00c 9 00 - 0x00c 9 0f not to be accessed dur- ing normal operation. channel0 current tx descriptor pointer (s0ctdp0) 0x00c 9 10 page 316 channel0 first tx descriptor pointer (s0ftdp0) 0x00c 9 14 page 316 bit 31=1 bit 30 =0 bit 31=1 bit 30 =0 bit 31=1 bit 30 =1 bit 31=1 bit 30 =1 bit 31=1 bit 30 =1 bit 31=1 bit 30 =1 idle loop GT-96100A advanced communication controller revision 1.0 321 channel1 channel1 configuration register (s0dc1) 0x010 9 00 for a description of the channel1 registers, see the descriptions for the channel 0 registers. channel1 command register (s0dcm1) 0x010 9 08 channel1 rx descriptor 0x018 9 00 - 0x018 9 0f channel1 current rx descriptor pointer (s0crdp1) 0x018 9 10 channel1 tx descriptor 0x01c 9 00 - 0x01c 9 0f channel1 current tx descriptor pointer (s0ctdp1) 0x01c 9 10 channel1 first tx descriptor pointer (s0ftdp1) 0x01c 9 14 channel2 channel2 configuration register (s0dc2) 0x020 9 00 for a description of the channel2 registers, see the descriptions for the channel 0 registers. channel2 command register (s0dcm2) 0x020 9 08 channel2 rx descriptor 0x028 9 00 - 0x028 9 0f channel2 current rx descriptor pointer (s0crdp2) 0x028 9 10 channel2 tx descriptor 0x02c 9 00 - 0x02c 9 0f channel2 current tx descriptor pointer (s0ctdp2) 0x02c 9 10 channel2 first tx descriptor pointer (s0ftdp2) 0x02c 9 14 channel3 channel3 configuration register (s0dc3) 0x030 9 00 for a description of the channel3 registers, see the descriptions for the channel 0 registers. channel3 command register (s0dcm3) 0x030 9 08 channel3 rx descriptor 0x038 9 00 - 0x038 9 0f channel3 current rx descriptor pointer (s0crdp3) 0x038 9 10 channel3 tx descriptor 0x03c 9 00 - 0x03c 9 0f channel3 current tx descriptor pointer (s0ctdp3) 0x03c 9 10 channel3 first tx descriptor pointer (s0ftdp3) 0x03c 9 14 table 320: sdma group 0 register map (continued) description offset page number GT-96100A advanced communication controller 322 revision 1.0 channel4 channel4 configuration register (s0dc4) 0x040 9 00 for a description of the channel4 registers, see the descriptions for the channel 0 registers. channel4 command register (s0dcm4) 0x040 9 08 channel4 rx descriptor 0x048 9 00 - 0x048 9 0f channel4 current rx descriptor pointer (s0crdp4) 0x048 9 10 channel4 tx descriptor 0x04c 9 00 - 0x04c 9 0f channel4 current tx descriptor pointer (s0ctdp4) 0x04c 9 10 channel4 first tx descriptor pointer (s0ftdp4) 0x04c 9 14 channel5 channel5 configuration register (s0dc5) 0x050 9 00 for a description of the channel5 registers, see the descriptions for the channel 0 registers. channel5 command register (s0dcm5) 0x050 9 08 channel5 rx descriptor 0x058 9 00 - 0x058 9 0f channel5 current rx descriptor pointer (s0crdp5) 0x058 9 10 channel5 tx descriptor 0x05c 9 00 - 0x05c 9 0f channel5 current tx descriptor pointer (s0ctdp5) 0x05c 9 10 channel5 first tx descriptor pointer (s0ftdp5) 0x05c 9 14 channel6 channel6 configuration register (s0dc6) 0x060 9 00 for a description of the channel6 registers, see the descriptions for the channel 0 registers. channel6 command register (s0dcm6) 0x060 9 08 channel6 rx descriptor 0x068 9 00 - 0x068 9 0f channel6 current rx descriptor pointer (s0crdp6) 0x068 9 10 channel6 tx descriptor 0x06c 9 00 - 0x06c 9 0f channel6 current tx descriptor pointer (s0ctdp6) 0x06c 9 10 channel6 first tx descriptor pointer (s0ftdp6) 0x06c 9 14 table 320: sdma group 0 register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 323 channel7 channel7 configuration register (s0dc7) 0x070 9 00 for a description of the channel7 registers, see the descriptions for the channel 0 registers. channel7 command register (s0dcm7) 0x070 9 08 channel7 rx descriptor 0x078 9 00 - 0x078 9 0f channel7 current rx descriptor pointer (s0crdp7) 0x078 9 10 channel7 tx descriptor 0x07c 9 00 - 0x07c 9 0f channel7 current tx descriptor pointer (s0ctdp7) 0x07c 9 10 channel7 first tx descriptor pointer (s0ftdp7) 0x07c 9 14 table 321: sdma group 1 register map description offset page number channel0 channel0 configuration register (s1dc0) 0x100 9 00 page 312 channel0 command register (s1dcm0) 0x100 9 08 page 314 channel0 rx descriptor 0x108 9 00 - 0x108 9 0f not to be accessed dur- ing normal operation. channel0 current rx descriptor pointer (s1crdp0) 0x108 9 10 page 316 channel0 tx descriptor 0x10c 9 00 - 0x10c 9 0f not to be accessed dur- ing normal operation. channel0 current tx descriptor pointer (s1ctdp0) 0x10c 9 10 page 316 channel0 first tx descriptor pointer (s1ftdp0) 0x10c 9 14 page 316 channel1 channel1 configuration register (s1dc1) 0x110 9 00 for a description of the channel1 registers, see the descriptions for the channel 0 registers. channel1 command register (s1dcm1) 0x110 9 08 channel1 rx descriptor 0x118 9 00 - 0x118 9 0f channel1 current rx descriptor pointer (s1crdp1) 0x118 9 10 channel1 tx descriptor 0x11c 9 00 - 0x11c 9 0f channel1 current tx descriptor pointer (s1ctdp1) 0x11c 9 10 channel1 first tx descriptor pointer (s1ftdp1) 0x11c 9 14 table 320: sdma group 0 register map (continued) description offset page number GT-96100A advanced communication controller 324 revision 1.0 channel2 channel2 configuration register (s1dc2) 0x120 9 00 for a description of the channel2 registers, see the descriptions for the channel 0 registers. channel2 command register (s1dcm2) 0x120 9 08 channel2 rx descriptor 0x128 9 00 - 0x128 9 0f channel2 current rx descriptor pointer (s1crdp2) 0x128 9 10 channel2 tx descriptor 0x12c 9 00 - 0x12c 9 0f channel2 current tx descriptor pointer (s1ctdp2) 0x12c 9 10 channel2 first tx descriptor pointer (s1ftdp2) 0x12c 9 14 channel3 channel3 configuration register (s1dc3) 0x130 9 00 for a description of the channel3 registers, see the descriptions for the channel 0 registers. channel3 command register (s1dcm3) 0x130 9 08 channel3 rx descriptor 0x138 9 00 - 0x138 9 0f channel3 current rx descriptor pointer (s1crdp3) 0x138 9 10 channel3 tx descriptor 0x13c 9 00 - 0x13c 9 0f channel3 current tx descriptor pointer (s1ctdp3) 0x13c 9 10 channel3 first tx descriptor pointer (s1ftdp3) 0x13c 9 14 channel4 channel4 configuration register (s1dc4) 0x140 9 00 for a description of the channel4 registers, see the descriptions for the channel 0 registers. channel4 command register (s1dcm4) 0x140 9 08 channel4 rx descriptor 0x148 9 00 - 0x148 9 0f channel4 current rx descriptor pointer (s1crdp4) 0x148 9 10 channel4 tx descriptor 0x14c 9 00 - 0x14c 9 0f channel4 current tx descriptor pointer (s1ctdp4) 0x14c 9 10 channel4 first tx descriptor pointer (s1ftdp4) 0x14c 9 14 table 321: sdma group 1 register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 325 channel5 channel5 configuration register (s1dc5) 0x150 9 00 for a description of the channel5 registers, see the descriptions for the channel 0 registers. channel5 command register (s1dcm5) 0x150 9 08 channel5 rx descriptor 0x158 9 00 - 0x158 9 0f channel5 current rx descriptor pointer (s1crdp5) 0x158 9 10 channel5 tx descriptor 0x15c 9 00 - 0x15c 9 0f channel5 current tx descriptor pointer (s1ctdp5) 0x15c 9 10 channel5 first tx descriptor pointer (s1ftdp5) 0x15c 9 14 channel6 channel6 configuration register (s1dc6) 0x160 9 00 for a description of the channel6 registers, see the descriptions for the channel 0 registers. channel6 command register (s1dcm6) 0x160 9 08 channel6 rx descriptor 0x168 9 00 - 0x168 9 0f channel6 current rx descriptor pointer (s1crdp6) 0x168 9 10 channel6 tx descriptor 0x16c 9 00 - 0x16c 9 0f channel6 current tx descriptor pointer (s1ctdp6) 0x16c 9 10 channel6 first tx descriptor pointer (s1ftdp6) 0x16c 9 14 channel7 channel7 configuration register (s1dc7) 0x170 9 00 for a description of the channel7 registers, see the descriptions for the channel 0 registers. channel7 command register (s1dcm7) 0x170 9 08 channel7 rx descriptor 0x178 9 00 - 0x178 9 0f channel7 current rx descriptor pointer (s1crdp7) 0x178 9 10 channel7 tx descriptor 0x17c 9 00 - 0x17c 9 0f channel7 current tx descriptor pointer (s1ctdp7) 0x17c 9 10 channel7 first tx descriptor pointer (s1ftdp7) 0x17c 9 14 table 321: sdma group 1 register map (continued) description offset page number GT-96100A advanced communication controller 326 revision 1.0 14. m ulti p rotocol s erial c ontroller (mpsc) the GT-96100A includes eight mpscs that support: ? bit oriented protocols (e.g. hdlc) ? byte oriented protocols (e.g. bisync) ? transparent protocols ? the uart (start/stop) mode. all eight mpscs can operate simultaneously. four mpscs can operate up to a guaranteed bit rate of 55mbps while the remaining mpscs can work up to guaranteed bit rate of 2mbps (in nrz/nrzi). all eight mpscs can be routed out via serial interface ports which implement interfaces like eia-232 and v.34. alternatively, the mpscs can be connected to the GT-96100A?s flextdms. a flextdm can also be used to con- nect the various mpscs to a pcm highway bus or any other time slot assigner bus. see section 15. ?flextdm units (ftdm)? on page 379 for a description of the flextdm. 14.1 dpll each mpsc has a dedicated transmit and receive digital phase lock loop (dpll). the transmit dpll encodes the transmit bit stream to the selected code and monitors the transmit clock for glitches. if a clock glitch is detected and the glitch detect enable (gde) bit in the main configuration register (mmcr) is set to ?1?, a maskable interrupt is generated. the receive dpll decodes the incoming bit stream according to the selected mode. if a code violation is detected (for example, no transition in manchester code) the de (decoding error) in the receive descriptor is set. the receive dpll also performs clock recovery from the incoming bit stream and monitors the receive clock for glitches. if a clock glitch is detected and the glitch detect enable (gde) bit in the main configuration register (mmcr) is set to ?1?, a maskable interrupt is generated. GT-96100A advanced communication controller revision 1.0 327 14.1.1 data encoding/decoding figure 57 shows the data encoding and decoding schemes the GT-96100A dpll supports. figure 57: mpsc dpll encoding/decoding schemes 14.1.2 dpll clock source each received dpll uses the mpsc receive clock input and each transmit dpll uses the mpsc transmit clock input as its source clock. note: the GT-96100A dplls can accept a clock source of up to 83mhz. this allows the GT-96100A to have a bit rate of up to 5mhz using a 16x clock rate scheme. 110010 nrz nrzi mark nrzi space fm1 (biphase mark) fm0 (biphase space) manchester differential manchester GT-96100A advanced communication controller 328 revision 1.0 14.1.3 receive dpll clock recovery when a mpsc is programmed to work in asynchronous mode, sampling rate on the dpll rx clock is config- urable between 8, 16, 32, which means that the user should supply the mpsc with a clock source that is 8x, 16x, 32x of the bit rate, respectively. the clock source for the mpsc's rx can be the sclk associated with that mpsc or one of the internal brg's outputs. selection of the mpsc's rx input clock is done using the rcrr register (see chapter 20, "physical signal routing" in the data sheet). when not synchronized, the dpll hunts for a start bit or edge. in uart mode, the dpll hunts for start bit. in hdlc bisync and transparent mode, the dpll hunts for an edge. if hunting for a start bit (uart), the dpll hunts for a falling edge, assuming it to be the beginning of a start bit. it then samples rxd at the middle of the bit, calculated from the falling edge of the start bit (8 ticks in x16 mode), to see that it is still ?0?. if not, it is consid- ered noise. a modulo 16 counter (for a 16x over-sampling rate) generates the receive clock rclk. in hdlc, bisync, and transparent modes, the dpll tries to lock itself on the transitions of the receive bit stream. when synchronization is achieved, the dpll continuously monitors for rising and falling edges as defined in the mpsc main configuration register (mmcr). when detecting an edge, the edge-compare logic gives the counter shift_left or shift_right commands to maintain lock on the received data. 14.2 mpscx main configuration register (mmcrx) each mpsc has an mpsc main configuration register (mmcrx). the mmcrx is a 64 bit register used to con- figure common mpsc features. it is protocol independent. the mmcrx consists of two 32 bits registers, mmcrhx and mmcrlx, as shown below. figure 58: mpsc main configuration register (mmcrx) unless otherwise specified: ? ?1? means set ? ?0? means not set ? ?0? is the default value after reset. cdm revd 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 098 7654 3210 base base + 4 ent mode ctsm ctss cds rtsm tci tidl tinv tsyn enr trx ttx rinv gde tsns lpbk tpl tppt tcdv tdec crcm rsl rcdv renc sedg mmcrlx mmcrhx trvd rrvd cdm rdw gdw nlm GT-96100A advanced communication controller revision 1.0 329 14.2.1 mpscx main configuration register low (mmcrlx) table 322: mpscx main configuration register low (mmcrlx), offset: 0x000a00, 0x008a00, 0x010a00, 0x018a00, 0x020a00, 0x028a00, 0x030a00, 0x038a00 (where x is the port number 0 to 7) bits field name function initial value 2:0 mode mode 000 -hdlc (default) 001 -reserved 010 -reserved 011 -reserved 100 -uart 101 -bisync 110 -reserved 111 -reserved 0 3 ttx transparent transmitter 0 - normal mode. (default) 1 - transparent mode. (transparent mode overrides the program mode in mode bits.) 0 4 trx transparent receiver 0 - normal mode (default) 1 - transparent mode. (transparent mode overrides the program mode in mode bits.) 0 5 reserved. 0 6 et enable transmit 0 - disabled. the tx channel is in low power mode. 1 - enable. the tx controller is ready for data. when the sdma has data to transmit it loads the data to the tx controller, that will transmit the data in the selected protocol. 0 7 er enable receive 0 - disabled. the rx channel is in low power mode. 1 - enable. the rx controller is ready to receive data. 0 9:8 lpbk loop back (for diagnostic) mode 00 -normal operation, no loopback (default) 01 -loopback 10 -echo 11 -loop back + echo in loopback mode, which is only for diagnostic purposes, the transmitted data on txd is fed into rxd. in this mode, the same clock source should be used for both rx and tx. echo mode re-transmits received data on rxd (with one clock delay) on txd. if cd* is asserted, the receiver also receives the incoming data. 00 GT-96100A advanced communication controller 330 revision 1.0 10 nlm null modem 0 - normal operation. the mpsc uses the cd* and cts* inputs to control the data flow 1 - null modem. the mpsc cd* and rts* internal signals are always asserted. the external pin status can be still read from the event register. note: for information about the behavior of the event register in different modes, see: ? section ?the esr register holds information on the transmit/ receive channel condition.? on page 345 . ? section 14.6.5.6 ?chr10 - bisync event status register (esr)? on page 360 . ? section 14.7.5.7 ?chr10 - uart event status register (esr)? on page 371 . ? section 14.8.2.3 ?chr10 - transparent event status register (esr)? on page 378 . 0 11 reserved. 0 12 tsyn transmitter synchronize to receiver setting this bit synchronizes the transmitter to receiver byte boundaries. this is particularly important in the x.21 protocol. 0 - no synchronization assumed. 1 - transmit bit stream is synchronized to the receive bit stream. this bit affects only a transparent transmitter. transmitter will start transmission nx8 bit period after the receive data arrives. if cts* is already asserted, the transparent transmitter will start transmit 8 clocks after the receiver starts to receive data. note: only this bit when transmit and receive clocks are equal and tcdv and rcdv are set to ?00?. 0 13 reserved. 0 table 322: mpscx main configuration register low (mmcrlx), offset: 0x000a00, 0x008a00, 0x010a00, 0x018a00, 0x020a00, 0x028a00, 0x030a00, 0x038a00 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 331 15:14 tsns transmit sense. defines the number of bit times the internal sense signal will stay active after last transition on the rxd line occurs. it is useful for appletalk protocol to avoid the spurious cd* change interrupt that would otherwise occur during the frame synchronization sequence that precedes the opening flag. the delay is a function of rcdv (clock divider) setting. 00 (rcdv = 0) - infinite (carrier sense is always active - default) 00 (rcdv 0) - infinite (carrier sense is always active - default) 01 (rcdv = 0) - 14 bit times 01 (rcdv 0) - 6.5 bit times 10 (rcdv = 0) - 4 bit times (normal appletalk) 10 (rcdv 0) - 2.5 bit times (normal appletalk) 11 (rcdv = 0) - 3 bit times 11 (rcdv 0) - 1 bit time 0 16 tidl transmit idles 0 - txd is encoded during data transmission (including preamble and flags/ sync patterns). txd is in mark during idle. (default.) 1 - txd is encoded all the time, even when idles are transmitted. table 323 . 0 17 rtsm rts* mode this bit may be changed on the fly. 0 - send idle between frames. rts* is negated between frames. idle pat- tern is defined by the protocol and tidl bit. 1- send flags/syncs between frames according to the protocol. rts* is always asserted. refer to table 323 . 0 18 reserved. 0 19 ctss cts* sampling mode 0 - asynchronous cts*. cts* is synchronized inside the GT-96100A. trans- mission starts after synchronization is achieved with a few cycles delay to the external cts*. (default) 1 - synchronous cts*. cts* is synchronized to the rx clock. this mode is recommended when connecting an mpsc to a flextdm. note: synchronous cts* must be used for isdn d channels. 0 20 cds cd* sampling mode 0 - asynchronous cd*. cd* is synchronized internally in the GT-96100A and then data is received. (default) 1 - synchronous cd*. cd* is synchronized to the rx clock. this mode is rec- ommended when connecting an mpsc to a flex-tdm. 0 table 322: mpscx main configuration register low (mmcrlx), offset: 0x000a00, 0x008a00, 0x010a00, 0x018a00, 0x020a00, 0x028a00, 0x030a00, 0x038a00 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller 332 revision 1.0 21 ctsm cts* operating mode 0 - normal mode. (envelop mode). cts* should envelop the frame. deasser- tion of cts* during transmission will cause a cts lost error. 1- pulse mode. once cts* is sampled low, synchronization has been achieved. further transitions of cts* have no effect. cts* synchronization will be lost when rts* is deasserted. 0 22 cdm cd* operating mode 0- normal mode. (envelop mode). cd* should envelop the frame. deasser- tion of cd* during reception will cause a cd lost error. 1- pulse mode. once cd* is sampled low, synchronization has been achieved. further transitions of cd* have no effect. 0 25:23 crcm crc mode 000 - crc16-ccitt (hdlc based protocols, e.g. x.25) (default) 001 - crc-16 (bisync) 010 - crc32-ccitt (hdlc based protocols, e.g. lap-d. identical to the ethernet crc) 011 - reserved 1xx- reserved 010 27:26 reserved. 0 28 trvd transmit reverse data 0 - normal mode. (default) 1 - reverse data mode. msb is shifted out first. 0 29 rrvd receive reverse data 0 - normal mode. (default) 1 - reverse data mode. msb is shifted in first. 0 30 reserved. 0 31 gde glitch detect enable 0 - normal mode. no glitch detect. (default) 1 - when glitch is detect, a maskable interrupt is generated. when this bit is set the mpsc looks for glitches in the external receive and transmit clocks. note: the GT-96100A tries to clean the input clocks by receiving them via a schmitt trigger input buffer. 0 table 322: mpscx main configuration register low (mmcrlx), offset: 0x000a00, 0x008a00, 0x010a00, 0x018a00, 0x020a00, 0x028a00, 0x030a00, 0x038a00 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 333 the following table summarizes the relationship between the tidl and rtsm 14.2.2 mpscx main configuration register high (mmcrhx) table 323: tidl/rtsm relationship rtsm/tidl txd rts* txd rts* 00 ?1? not encoded 1 data encoded 0 01 ?1? encoded 1 data encoded 0 10 flags/not encoded 0 data encoded 0 11 flags/encoded 0 data encoded 0 table 324: mpscx main configuration register high (mmcrhx), offset: 0x000a04 , 0x008a04, 0x010a04, 0x018a04, 0x020a04, 0x028a04, 0x030a04,0x038a04 (where x is the port number 0 to 7) bits field name function initial value 0 tci transmit clock invert 0 - normal operation - data is shifted out on the falling edge. (default.) 1 -the internal transmit clock is inverted by the mpsc before it is used. this allows the mpsc to clock data out half a cycle earlier on the rising edge of the clock. 0 1 tinv transmit bit stream inversion 0 - no invert. 1 - invert the data before it is sent to the dpll. setting tinv to ?1? generates fm1 from fm0, nrzi mark from nrzi space, etc. it also inverts the bit stream in nrz mode. 0 4:2 tpl transmit preamble length determines the number of preamble bytes the transmitter sends before it starts to transmit data. the send pattern is defined by the tppt bits. 000 - no preamble (default) 001 - 1 byte 010 - 2 bytes 011 - 4 bytes 100 - 6 bytes 101 - 8 bytes 110 - 16 bytes 111 - reserved 0 8:5 tppt transmit preamble pattern defines a character sent as a preamble sequence. two tppt characters form a preamble byte. the number of preamble bytes sent is defined by the tpl field. the receiving dpll uses the preamble pattern to lock on the receiving signal. 0 GT-96100A advanced communication controller 334 revision 1.0 10:9 tcdv transmit clock divider defines the transmit clock divider. the transmit bit rate is the rate of the clock entering the mpsc tx machine (from external pin or a brg) divided by the tcdv field. for fm0, fm1, manchester, and differential manchester, one of the 8x, 16x, or 32x options must be set. 00 - 1x clock mode (default. for nrz and nrzi only.) 01 - 8x clock mode 10 - 16x clock mode 11 - 32x clock mode 0 13:11 tdec transmit encoder specifies the encoding method for the dedicated tx channel dpll. 000 - nrz (default) 001 - nrzi (mark, can be set to space by setting tinv bit) 010 - fm0 (can be set to fm1 by setting the tinv bit) 011 - reserved 100 - manchester 101 - reserved 110 - differential manchester 111 - reserved 0 15:14 reserved. 0 16 rinv receive bit stream inversion. 0 - no invert. 1 - inverts the data before it is sent from the dpll to the mpsc data path. setting rinv to ?1? decodes fm1 and nrzi mark when the renc field is programed to fm0 and nrzi space etc. it also inverts the received bit stream in nrz mode. 0 20:17 gdw clock glitch width when the gde bit is set, the mpsc will consider tx/rx clock pulses that are narrower than gdw system clocks as a glitch. 0 21 reserved. 0 table 324: mpscx main configuration register high (mmcrhx), offset: 0x000a04 , 0x008a04, 0x010a04, 0x018a04, 0x020a04, 0x028a04, 0x030a04,0x038a04 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 335 22 rdw receive data width 0 - normal mode. the mpsc data path is 16 bits wide. upon receiving 16 bits, the data is transferred into the sdma fifos. buffers must be 64-bit word aligned. dma bursts are enabled. note: normal mode must be used for hdlc based protocols. 1 - low latency operation. data is transferred to the fifos after 8 bits are received. logical fifo width is one byte. note: this mode allows byte aligned buffers. this mode must be chosen for bisync and uart modes. dma bursts are disabled. the sdma writes one byte per dram access. setting rdw also bypasses the receive fifo threshold. the sdma arbitrates for dma access as soon as the fifo has one byte in it. 0 24:23 rsyl receive sync length (bisync and transparent modes) 00 - external sync (cd* assertion) 01 - 4-bit sync 10 - 8-bit sync (monosync) 11 - 16-bit sync (bisync) 0 26:25 rcdv receive clock divider defines the receive clock divider. the receive bit rate is the rate of the clock entering the mpsc rx machine (from external pin or a brg) divided by the rcdv field. for fm0, fm1, manchester, and differential manchester, one of the 8x, 16x, or 32x options must be set. 00 - 1x clock mode (default. for nrz and nrzi only.) 01 - 8x clock mode 10 - 16x clock mode 11 - 32x clock mode 0 29:27 renc receive encoder specifies the encoding method for the dedicated rx channel dpll. 000 - nrz (default) 001 - nrzi (mark, can be set to space by setting rinv bit) 010 - fm0 (can be set to fm1 by setting the rinv bit) 011 - reserved 100 - manchester 101 - reserved 110 - differential manchester 111 - reserved 0 table 324: mpscx main configuration register high (mmcrhx), offset: 0x000a04 , 0x008a04, 0x010a04, 0x018a04, 0x020a04, 0x028a04, 0x030a04,0x038a04 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller 336 revision 1.0 31:30 sedg synchronization clock edge the clock edge used by the dpll for adjusting the receive sample point due to drift in the receive signal. 00 - both rising and falling edges. (default.) 01 - rising edge 10 - falling edge 11 - no adjustment 0 table 324: mpscx main configuration register high (mmcrhx), offset: 0x000a04 , 0x008a04, 0x010a04, 0x018a04, 0x020a04, 0x028a04, 0x030a04,0x038a04 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 337 14.3 mpscx protocol configuration registers (mpcrx) each mpsc has a dedicated protocol configuration register (mpcrx). the mpcrx registers are located at base+08 relative to the corresponding mpsc main configuration register (mmcrx). the functionality of the mpcrx is protocol dependent. detailed descriptions of the mpcrs are given in the following protocol sections. 14.4 channel registers (chxrx) each mpsc and the ethernet controller has ten dedicated channel registers (chxrx) to program the mpsc or ethernet controller. the chxrx registers are located at base+0xc0 through base+0x30 relative to the corresponding mpsc main configuration register (mmcrx). the functionality of the chxrx is protocol dependent. detailed descriptions of the chrs are given in the following protocol sections. 14.5 hdlc mode 14.5.1 hdlc receive/transmit operation in hdlc mode, an mpsc performs the following protocol functions: ? flag generation and stripping ? bit stuffing and stripping ? address recognition (up to 16 bit addresses) ? crc generation and checking ? line condition monitoring ? localtalk preamble generation ? localtalk trailing abort generation figure 59: typical hdlc frame figure 60: typical localtalk frame flag address control information crc flag 8 bits 8/16/8n bits 8/16 bits 8n bits (optional) 16/32 bits 8 bits crc flag 8 bits 8bits 8 bits 0 -598 bytes 16 bits 8 bits des add src add flag llap type length data ppulse 10 bits 8bits > 3 bits at least the preamble bit is not decoded. abort 12-18 bits flag 8 bits 6 reserved bits GT-96100A advanced communication controller 338 revision 1.0 14.5.2 sdmax command/status field for hdlc mode when an mpsc is in hdlc mode, the command/status field in the corresponding sdmax descriptor has the following format: table 325: sdmax command/status field for hdlc mode bit rx - function tx - function 0 ce - crc error reserved 1 cdl - cd loss ctsl - cts loss 2 de - decoding error reserved 3 no - non octet frame d-deferred. transmission was deferred due to busy channel. 4 abr - abort sequence/residue[0] reserved 5 residue[1] reserved 6 or - data overrun/residue[2] ur - data underrun 7 mfl - max frame length err reserved 8 sf - short frame rl - retransmit limit error 9 reserved col - collision occurred 13:10 reserved rc-retransmit count (lan hdlc mode only) 14 reserved reserved 15 es - error summary es = ce || cdl || de || no || abr || or || mfl || sf 1 1. ?||? means logical or. error summary es = ctsl || ur || rl 1 16 l - last l - last 17 f - first f - first 21:18 reserved reserved 22 reserved gc - generate crc 23 ei - enable interrupt ei - enable interrupt 29:24 reserved reserved 30 am - auto mode am - auto mode 31 o -owner o - owner GT-96100A advanced communication controller revision 1.0 339 14.5.3 mpscx protocol configuration register (mpcrx) for hdlc figure 61: mpscx protocol configuration register (mpcrx) for hdlc table 326: mpscx protocol configuration register (mpcrx) for hdlc, offset: 0x000a08 , 0x008a08, 0x010a08, 0x018a08, 0x020a08, 0x028a08, 0x030a08, 0x038a08 (where x is the port number 0 to 7) bits field name function initial value 1:0 reserved. 0 2 lct local talk when set, the following localtalk support is added to the hdlc controller: ? two abort sequences will be generated at the end of frame follow- ing its closing flag. ? a preamble will be generated. no encoding will be done for the last preamble bit when working with localtalk, the fm0 encoding scheme should be set by writing ?010? to renc and tdec in the mmcrx. the user should also set tppt to 0xf and tpl to ?1? (one byte preamble). the last preamble bit is not decoded. this must be done for localtalk rts frames. setting tpl to ?0? leads to a frame without preamble. this can be used with localtalk data frames. setting tpl to other values leads to unpredictable results. 0 3 reserved. 0 4 ccm crc compliance mode. in hdlc, the tx side uses bit stuffing to prevent a data/crc pattern from looking like an hdlc control flag. the ccm tells the rx side how to handle frames that were received with mistakes in bit stuffing, when they occur immediately before the end flag. this is a borderline condition that may or may not present a problem in actual systems. 0 - compatible mode. if the rx side receives a frame that is missing a stuffed bit that is supposed to be immediately before the end flag, then mark in the descriptor that the frame has a good crc, and pass the good crc along to the buffer. 1 - compliance mode. if the rx side receives a frame that is missing a stuffed bit that is supposed to immediately proceed the end flag, then mark in the descriptor that the frame has a bad crc, and pass the errored crc to the buffer. 5 reserved. 0 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 098 76543210 base + 08 mpcrx nof clm drt lct ccm GT-96100A advanced communication controller 340 revision 1.0 6 drt disable rx on tx when drt is set to ?1? the rx path is closed during tx. this is useful in mul- tidrop configurations when a user doesn?t want to receive its own frames. 0 8:7 reserved. 0 9 clm collision mode. when set to ?1?, the mpsc transceiver tries to retransmit a frame after a cts lost. this mode allows automatic collision resolution for an isdn lap-d type channel. 0 11:10 reserved. 0 15:12 nof number of flags specifies the number of flags transmitted between consecutive frames. setting nof to ?0? specifies shared flag mode. in shared flag mode, the clos- ing flag of a frame is used as the opening flag of the following frame. this setting also puts the receiver in back-to-back mode. the default value is 1. 1 31:16 reserved. 0 table 326: mpscx protocol configuration register (mpcrx) for hdlc, offset: 0x000a08 , 0x008a08, 0x010a08, 0x018a08, 0x020a08, 0x028a08, 0x030a08, 0x038a08 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 341 14.5.4 channel registers (chxrx) for hdlc mode figure 62: channel registers (chxrx) for hdlc 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 098 76543210 base + 0c base + 10 chr1 - synr chr2 - cr base + 14 chr3 - mflr base + 30 base + 18 chr4 - adfr base + 1c chr5 base + 20 chr6 - adlr base + 24 chr7 - adhr base + 28 chr8 base + 2c sync max frame length ad2 ad4 ad3 ad1 bce eh aa bn abort chr9 chr10 - esr short frames cts cd tidle rhs rlidl dpcs rrf GT-96100A advanced communication controller 342 revision 1.0 unless otherwise specified: ? ?1? means set. ? ?0? means not set. ? ?0? is the default value after reset. table 327: chxr1 - sync/abort register (synr), offset: 0x000a0c, 0x008a0c, 0x010a0c, 0x018a0c, 0x020a0c, 0x028a0c, 0x030a0c, 0x038a0c (where x is channel 0 to 7) bits field name function initial value 7:0 sync holds the synchronization pattern for the receive machine and opening/ closing flag/sync-pattern for the transmit machine. this is an hdlc abort pattern so no additional programing is needed for the hdlc protocol. 7e 15:8 reserved 0 23:16 abort the abort pattern is transmitted upon receiving an abort command or when an underrun event occurs. this is an hdlc abort pattern so no additional programing is needed for the hdlc protocol. fe 31:24 reserved 0 table 328: chxr2 - command register (cr), offset: 0x000a10, 0x008a10, 0x010a10, 0x018a10, 0x020a10, 0x028a10, 0x030a10, 0x038a10 (where x is channel 0 and 7) bits field name function resetv value 6:0 reserved. 0 7 a abort transmission abort transmission immediately and go to idle. the descriptor is not closed or incremented. note: command is not synchronized to byte. 0 22:8 reserved. 0 23 a abort reception abort receive immediately and go to idle. the descriptor is not closed or incremented. the processor must issue enter hunt command after abort command in order to enable reception. the bit is cleared upon entering idle state. after executing an abort reception, the cpu must disable the tx sdma channel. the cpu then needs to execute a normal initialization process to the mpsc. 0 30:24 reserved. 0 GT-96100A advanced communication controller revision 1.0 343 notes: the et bit in the main configuration register must be set to ?1? before issuing the following transmit demand, stop transmission, or abort transmission commands. the er bit in the main configuration register must be set to ?1? before issuing the enter hunt or abort reception commands. when the et or er bits are deasserted, the mpscx transmit/receive channel is in low power mode (no clock). issuing one of the above commands in this state will lead to unpredictable results. 31 eh enter hunt upon receiving the enter hunt command, the receive machine moves to hunt state and continuously searches for an opening flag. if enter hunt mode command is issued during frame reception, the current descriptor is closed with crc error 1 . the eh bit is cleared upon entering hunt state. 0 n/a td transmit demand fetch a descriptor and start transmission. issued through the sdmax command register. n/a stop stop complete frame transmission and stop. (go to idle). issued through the sdmax command register. 1. the reception process for this purpose begins after proper address recognition is allowed. before achieving an address match, the receiver goes to enter hunt state without closing the descriptor. table 329: chxr3 - maximum frame length register (mflr), offset: 0x000a14, 0x008a14, 0x010a14, 0x018a14, 0x020a14, 0x028a14, 0x030a14, 0x038a14 (where x is channel 0 and 7) bits field name function initial value 15:0 flbr frame length buffer register holds the maximum allowed frame length. when a frame exceeds the num- ber written in the flbr, the remainder of the frame is discarded. the hdlc controller waits for a closing flag and then returns the frame status with bit 7 (mfle) set to ?1?. 0xffff 31:16 reserved. 0 table 328: chxr2 - command register (cr), offset: 0x000a10, 0x008a10, 0x010a10, 0x018a10, 0x020a10, 0x028a10, 0x030a10, 0x038a10 (where x is channel 0 and 7) bits field name function resetv value GT-96100A advanced communication controller 344 revision 1.0 table 330: chxr4 - address filtering register (adfr), offset: 0x000a18, 0x008a18, 0x010a18, 0x018a18, 0x020a18, 0x028a18, 0x030a18, 0x038a18 (where x is channel 0 and 7) bits field name function initial value 15:0 bce bit comparison enable bits setting ?1? in one of the bce bits enables the address comparison for this bit: ? for 16-bit lap-d like address recognition, write 0xffff in adfr. ? for 8-bit hdlc/lap-b like address recognition, write 0x00ff in adfr. ? for reception of a predefined address group, write ?0? to the appro- priate bits to disable address comparison on these bits. 0 28:16 reserved. 0 29 n null enable enables the reception of hdlc null address (0x0000 or 0x00 depending on the bce setting) 0 30 reserved. 0 31 b broadcast enable enables the reception of hdlc broadcast address (0xffff or 0xff, depending on the bce setting). 0 table 331: chxr5 - short frame register (shfr), offset: 0x000a1c, 0x008a1c, 0x010a1c, 0x018a1c, 0x020a1c, 0x028a1c, 0x030a1c, 0x038a1c (where x is channel 0 and 7) bits field name function initial value 2:0 shfr short frame register setting shfr to ?1? enables the short frame error report. short frames are frames with byte count less than 3+shfr. 0 31:3 reserved. 0 table 332: chxr6 - address 1 and 2 register (adlr), offset: 0x000a20, 0x008a20, 0x010a20, 0x018a20, 0x020a20, 0x028a20, 0x030a20, 0x038a20 (where x is channel 0 and 7) bits field name function reset value 15:0 ad1 address 1 a 16-bit address that can be used for receive address recognition. 0 31:16 ad2 address 2 a 16-bit address used for receive address recognition. 0 GT-96100A advanced communication controller revision 1.0 345 the esr register holds information on the transmit/receive channel condition. chr10 can be read by the cpu for channel condition resolution. some changes in the channel condition can generate maskable interrupts, as shown below. table 333: chxr7 - address 3 and 4 register (adhr), offset: 0x000a24, 0x008a24, 0x010a24, 0x018a24, 0x020a24, 0x028a24, 0x030a24, 0x038a24 (where x is channel 0 and 7) bits field name function reset value 15:0 ad3 address 3 a 16-bit address that can be used for receive address recognition. 0 31:16 ad4 address 4 a 16-bit address that can be used for receive address recognition. 0 table 334: chxr8 - reserved, offset: 0x000a28, 0x008a28, 0x010a28, 0x018a28, 0x020a28, 0x028a28, 0x030a28, 0x038a28 (where x is channel 0 and 7) bits field name function initial value 31:0 reserved. note: do not access this register in the hdlc mode. 0 table 335: chxr9 - reserved, offset: 0x000a2c, 0x008a2c, 0x010a2c, 0x018a2c, 0x020a2c, 0x028a2c, 0x030a2c, 0x038a2c (where x is channel 0 and 7) bits field name function reset value 31:0 reserved. note: do not access this register in the hdlc mode. 0 GT-96100A advanced communication controller 346 revision 1.0 table 336: chxr10 - event status register (esr), offset: 0x000a30, 0x008a30, 0x010a30, 0x018a30, 0x020a30, 0x028a30, 0x030a30, 0x038a30 (where x is channel 0 and 7) bits field name function initial value 0 cts clear to send signal an interrupt is generated when this signal is deasserted during transmit. 0 1 cd carrier detect signal an interrupt is generated when this signal is deasserted during receive. 0 2 reserved. 0 3 tidle tx in idle state. an interrupt is generated upon entering idle state. 0 4 reserved. 0 5 rhs rx in hunt state. 0 10:6 reserved. 0 11 rlidl 1 = rx idle line 0 12 dpcs 1 = dpll carrier sense. 0 13 rrf 1 = rx receiving flags. 0 31:14 reserved. 0 GT-96100A advanced communication controller revision 1.0 347 14.6 bisync mode the GT-96100A bisync controller was designed to reduce cpu overhead by executing most of the protocol requirements for bisync/monosync mode without cpu interference. when auto transparent mode is enabled, the GT-96100A automatically switches to the transparent receive mode upon receiving a dle stx sequence. other features are controlled by programming the bank of control registers. figure 63: typical bisync/monosync frames 14.6.1 bisync transmit operation in bisync mode an mpsc handles the following protocol functions: ? leading sync character transmission before a buffer with f bit set. ? optional 32-bit transmission before the sync transmission. ? dle transmission before a buffer with the td bit set. ? bcc generation: - bcc (crc-16, vrc/lrc and vrc/crc-16) is calculated. - buffers with bce set to ?0? are excluded from bcc calculation. - crc reset is controlled from the rc bit in tx descriptor. - the calculation of bcc is sent or discarded according to the gc bit in the tx descriptor. ? automatic stuffing of dle when transmitting a transparent buffer (buffer with tr bit set). ? sync transmission if underrun occurs. bisync transmission is descriptor chain oriented. transmission starts when the cpu issues a transmit demand command and continues until the channel?s sdma reaches a null pointer or a ?not owned? descriptor. header text bcc syn etx soh stx or etb bisync text with header data crc syn monosync syn text bcc syn etx stx or etb bisync text without header syn text bcc syn etx dle dle or etb bisync transparent syn stx GT-96100A advanced communication controller 348 revision 1.0 14.6.2 bisync receive operation there are two major operating modes in the bisync receiver. 14.6.2.1 bisync normal receive mode in normal mode, the bisync receiver handles the following protocol functions: ? bisync, monosync, nibblesync or external sync synchronization. ? auto sync stripping in text mode. ? auto dle-sync stripping in transparent text mode. ? auto sync stripping after receiving dle itb in transparent mode. ? automatic exit of transparent mode after receiving dle-etx/etb (if rtr bit in the mpcrx was cleared). ? marking of buffers that contain transparent data by setting the tb bit in the descriptor. ? bcc generation: - bcc (crc-16, vrc/lrc and vrc/crc-16) is calculated. - in transparent text mode, crc-16 always overrides the vrc. - sync (dle-sync) is not included in the bcc calculation. ? buffer closing at the reception of etx, etb, itb and enq. ? maintaining sync (stay in text mode) after itb. ? protocol correctness checking: - test for ?1? padding at the end of block reception. (the cpu should ignore a padding error reported after itb, and can use it when testing for proper nak or eot.) - test for dle-ctl after receiving dle-itb in transparent text mode. if another sequence arrives (except syncs), buffer is closed with dle error. table 337: bisync receiver operating modes mode function normal mode the cpu must monitor each received byte and manage each bisync opera- tion (e.g., moving into transparent mode) manually. auto transparent mode the GT-96100A handles transparent mode automatically. this mode reduces the cpu burden since it can monitor the incoming data buffer-by-buffer and not byte-by-byte. GT-96100A advanced communication controller revision 1.0 349 14.6.2.2 bisync auto transparent receive mode in auto transparent mode, the bisync receiver handles the following protocol functions: ? bisync, monosync, nibblesync, or external sync synchronization. ? auto sync stripping in text mode. ? auto dle-sync stripping in transparent text mode. ? auto sync stripping after receiving dle itb in transparent mode. ? automatic switch to transparent mode after receiving dle-stx. ? automatic exit of transparent mode after receiving dle-etx/etb. ? marking of buffers that contain transparent data by setting the tb bit in the descriptor. ? bcc generation: - bcc (crc-16, vrc/lrc and vrc/crc-16) is calculated. - in transparent text mode, crc-16 always overrides the vrc. - sync (dle-sync) is not included in the bcc calculation. - opening stx/soh (dle-stx) are discarded from bcc calculations. ? buffer closing at the reception of etx, etb, itb, and enq. ? maintaining sync (stay in text mode) after itb. ? buffer closing after syn-syn-dle-char (when char is not stx). ? protocol correctness checking: - test for ?1? padding at the end of block reception. (the cpu should ignore a padding error reported after itb, and can use it when testing for proper nak or eot.) - test for dle-ctl (ctl is a control character with b or h set) after receiving dle-itb in transparent text mode. if another sequence arrives (except syncs), buffer is closed with a dle error. the bisync receive process is block oriented. a block starts after a buffer was closed due to control character reception, overrun, protocol error, parity error, or line error (i.e. cd deassertion). the first descriptor in a block is marked with f bit set to ?1?. the last descriptor in block is marked with l bit set to ?1?. the last descriptor also includes the actual status report for the block. intermediate descriptors can be rec- ognized by having both f and l bit set to ?0?. GT-96100A advanced communication controller 350 revision 1.0 14.6.3 sdmax command/status field for bisync mode when an mpsc is in bisync mode the command/status field in the corresponding sdmax descriptor has the following format: table 338: sdmax command/status field for bisync mode bits rx - function tx - function 0 ce - crc/lrc error reserved 1 cdl - cd loss ctsl - cts loss 2 de - decoding error reserved 3 dle - dle error. while in transparent mode, this indicates a dle was received and the fol- lowing byte was not a valid control character. reserved 4 pr - parity error. last byte in buffer has parity error. reserved 5 reserved reserved 6 or - data overrun reserved 8:7 reserved reserved 9 pdr - pad report. this is set if there were no four consecutive ?1?s after the block reception. reserved 10 reserved reserved 11 tb - transparent buffer. buffer contains trans- parent data. reserved 12 reserved reserved 13 c - last bytes in buffer is a user defined control character. reserved 14 b - last bytes in buffer are bcc. reserved 15 es - error summary es = cdl || de || dle || pr || or es - error summary es = ctsl 16 l - last l - last note: transmit bit 22 is used only if l bit is set to ?1?. if l bit is set to ?0?, no bcc is sent at the end of this buffer transmis- sion. 17 f - first f - first GT-96100A advanced communication controller revision 1.0 351 14.6.4 mpscx protocol configuration register (mpcrx) for bisync figure 64: mpscx protocol configuration register (mpcrx) for bisync 18 reserved tr - transparent mode. ? 0 - normal mode. sync will be sent in case of underrun ? 1 - transparent mode. dle-sync will be sent in case of underrun. crc-16 will be used. 19 reserved td - transmit dle before transmitting the buffer. this bit is valid only for transparent buff- ers. the preceding dle is not included in the bcc calculations. 20 reserved bce - bcc enable ? 0 - buffer must be excluded from bcc calculations ? 1 - buffer must be included in bcc calculation 21 reserved rc - reset bcc ? 0 - bcc/lrc is accumulated. ? 1 - bcc/lrc is reset. 22 reserved gc - generate bcc/lrc. 23 ei - enable interrupt ei - enable interrupt 29:24 reserved reserved 30 am - auto mode am - auto mode 31 o - owner o - owner table 338: sdmax command/status field for bisync mode (continued) bits rx - function tx - function 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 098 76543210 base + 08 mpcrx drt tsm atm rdb rtr trp GT-96100A advanced communication controller 352 revision 1.0 table 339: mpscx protocol configuration register (mpcrx) for bisync, offset: 0x000a08 , 0x008a08, 0x010a08, 0x018a08, 0x020a08, 0x028a08, 0x030a08, 0x038a08 (where x is the port number 0 to 7) bits field name function initial value 1:0 reserved. 0 2 atm auto transparent mode 0 - normal mode. 1 - receiver switches to transparent mode after receiving dle-stx and exits transparent mode upon receiving a dle-etb or dle-etx sequence. when switching to transparent mode, new buffers are opened for transpar- ent data. when the atr bit is set to ?1? the following characters should be programed into ctl1-8: ?ctl3 - stx ?ctl4 - soh note: when entering transparent mode either automatically or by issu- ing an rtr command, the receiver will strip automatically lead- ing dles. the tb bit in the descriptor will be set to signal the software that the buffer contains transparent data. 0 5:3 reserved. 0 6 drt disable rx on tx when drt is set to ?1? the rx path is closed during tx. this is useful in a multidrop configuration when a user doesn?t want to receive its own frames. 0 9:7 reserved. 0 10 trp trailing pad when set, the bisync transmitter sends a pad character (0xff) at the end of each outgoing frame (i.e. after a buffer with l bit set.) 0 12:11 reserved. 10 13 rtr receive transparent mode 0 - the receiver is placed in normal mode with sync stripping and control character recognition operative. 1 - the receiver is placed in transparent mode. syncs dles and control characters are recognized only after leading dle characters. crc16 is cal- culated even in vrc/lrc mode while in transparent mode. note: when entering transparent mode either automatically or by issu- ing an rtr command, the receiver automatically strips leading dles. the tb bit in the descriptor is set to signal the software that the buffer contains transparent data. 0 GT-96100A advanced communication controller revision 1.0 353 14.6.5 channel registers (chxrx) for bisync mode figure 65: channel registers (chxrx) for bisync 14 rdb receive discard from bcc when this bit is set, the received byte is not included in the bcc. the soft- ware must set this bit within the byte time window that starts when the char- acter is in the rx machine internal buffer. (the software can use the bisync interrupts for proper synchronization.) this bit is used in software to control bisync. the GT-96100A clears the rdbcc bit after discarding the required byte from bcc. 0 15 tsm tx sync mode 0 - two sync characters are transmitted. 1 - 32 sync characters are transmitted. note: the tx machine sends at least two bytes even in monosync or nibblesync modes. 0 31:16 reserved 0 table 339: mpscx protocol configuration register (mpcrx) for bisync, offset: 0x000a08 , 0x008a08, 0x010a08, 0x018a08, 0x020a08, 0x028a08, 0x030a08, 0x038a08 (where x is the port number 0 to 7) (continued) bits field name function initial value 1098765432109876543210987654 3210 base +0c base + 10 chr1 - sdr chr2 - cr base + 14 chr3 chr10 base + 18 chr4 - cfr base + 1c chr5 - ctlr1 base + 20 chr6 - ctlr2 base + 24 chr7 - ctlr3 base + 2c chr8 - ctlr4 base + 30 chr9 sync ctl4/soh ctl6 ctl5 ctl3/stx bce a dle tel eh a ctl2 ctl1 base + 34 event ctl8 ctl7 rbc crd tpm rpm rev tev rel v v 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 tlrm rlrm GT-96100A advanced communication controller 354 revision 1.0 unless otherwise specified: ? ?1? means set ? ?0? means unset. ? ?0? is the default value after reset. 14.6.5.1 chr1 - sync/dle register (sdr) chr1[7:0] holds the sync character and chr1[23:16] holds the dle character for the channel. after reset it holds the value of 7e in the sync field and fe in the dle field. the user must write the appropriate values before enabling the rx/tx machines. if bit 15 is set, the bisync receive machine discards the sync patterns received in a middle of a message. note: this usually happens when the transmitter experiences underrun. if bit [15] is ?0? the sync characters is transferred to the receive buffer. if bit 31 is ?1?, the first dle received in transparent mode is discarded. if bit 31 is ?0?, the bisync receiver is not discard dle in transparent mode. a bisync transmitter always stuffs the leading dle before transmitting the dle that is part of a transparent buffer (transmit descriptor with tr bit set). in order to send dle etx, for example, the cpu must either prepare a buffer that contains dle etx and set tr=?0?, or prepare a buffer with etx and program the transmitter to send a leading dle by setting the td bit in the descriptor. a bisync transmitter always transmits sync-sync at the beginning of a frame. this is true in monosync and nibblesync modes. when a bisync transmitter experiences underrun it transmits continuous sync patterns in text mode or dle- sync in transparent mode. the bisync transmitter exits this state upon receiving new data or when the cpu issues a stop or abort command. the receiver sync length is programmable. the actual length is determined according to the value of the rsyl bits in the mmcrx. if the rsyl bits equal #00b, the synchronization is done externally and the receiver will start receiving when cd* is asserted. in nibblesync mode, bits [7:4] are used by the receiver for sync recognition. bits [3:0] should return the sync pattern in order to assure proper sync transmission. GT-96100A advanced communication controller revision 1.0 355 14.6.5.2 chr2 - command register (cr) table 340: chxr2 - command register (cr), offset: 0x000a10, 0x008a10, 0x010a10, 0x018a10, 0x020a10, 0x028a10, 0x030a10, 0x038a10 (where x is channel 0 and 7) bits field name function initial value 0 tel tx enable longitudinal redundancy check 0 - lrc is disabled. 1 - lrc is enabled. (tel default value is 0 and the cpu must write ?1? to it in order to enable lrc). when set, tel overrides the crc mode that was programed in the crcm field in the mmcrx. 0 1 tev tx enable vertical redundancy check (parity bit) 0 - vrc is disabled. 1 - vrc is enabled. (tev default value is ?0? and the cpu must write ?1? to it in order to enable vrc). 0 3:2 tpm transmit parity mode 00 - odd 01 - low (always ?0?) 10 - even 11 - high (always ?1?) 0 4 tlrm transmit longitudinal redundancy mode 0 - odd 1 - even 1 6:5 reserved. 0 7 a abort transmission abort transmission immediately and go to idle. the descriptor is not closed or incremented. note: command is not synchronized to byte. 0 15:8 reserved. 0 16 rel rx enable longitudinal redundancy check. 0 - lrc is disabled. 1 - lrc is enabled. this is the normal mode for bisync. when set, rel overrides the crc mode that was programed in the crcm field in the mmcrx. 0 17 rev rx enable vertical redundancy check (parity bit). 0 - vrc (parity) is disabled. 1 - vrc is enabled. this is the normal mode for bisync. 0 19:18 rpm receive parity mode 00 - odd 01 - low (always ?0?) 10 - even 11 - high (always ?1?) 0 GT-96100A advanced communication controller 356 revision 1.0 20 rlrm receive longitudinal redundancy mode 0 - odd 1 - even 1 22:21 reserved. 0 23 a abort reception abort receive immediately and go to idle. the descriptor is not closed or incremented. the processor must issue an enter hunt command after an abort command to enable reception. the a bit is cleared upon entering idle state. 0 24 reserved. 0 25 crd close rx descriptor when the cpu issues a crd command the current receive descriptor is closed and the following received data is sdma?d into a new buffer. if there is no active receive in process, no action takes place. 0 28:26 reserved. 0 29 rbc reset bcc the cpu issues an rbc command in order to manually reset the crc- lrc/vrc generator. the bcc calculation starts with the next byte. the GT-96100A clears the rbc bit after resetting bcc. 0 30 reserved. 0 31 eh enter hunt upon receiving an enter hunt command, the receive machine will move to a hunt state and will continuously search for an opening sync or external sync. if an enter hunt mode command is issued during frame reception, the current descriptor will be closed with a crc error. the eh bit will be cleared upon entering a hunt state. 0 na td transmit demand fetch a descriptor and start transmission. issued through the sdmax command register. na stop stop transmission complete frame transmission and stop. (go to idle). issued through the sdmas command register. table 340: chxr2 - command register (cr), offset: 0x000a10, 0x008a10, 0x010a10, 0x018a10, 0x020a10, 0x028a10, 0x030a10, 0x038a10 (where x is channel 0 and 7) bits field name function initial value GT-96100A advanced communication controller revision 1.0 357 the et bit in the main configuration register must be set to ?1? before issuing any of the following commands: ? transmit demand. ? stop transmission. ? abort transmission. the er bit in the main configuration register must be set to ?1? before issuing any of the following commands: ? enter hunt ? reset bcc ? close rx descriptor ? abort reception. when the et or er bits are deasserted, the mpscx transmit/receive channel is in low power mode (no clock). note: issuing one of the above commands in this state will lead to unpredictable results. setting tel=?0?, tev=?1? and crcm=?001?, or setting rel=?0?, rev=?1? and crcm=?001?, will set the bisync transmitter/receiver to work in vrc+crc16 mode. the calculated parity bit is considered part of the data that the crc-16 checks. when a bisync transmitter transmits a transparent buffer, it automatically switches to the crc that was pro- grammed in the crcm field in mmcrx. when a receiver enters transparent mode, it automatically switches to the crc that was programed in crcm field in mmcrx. in both cases, crcm must be programed to ?001? in order to meet the bisync crc-16 specifications. 14.6.5.3 chr4 - control filtering register (cfr) bits 7:0 of the cfr register are the bit comparison enable bits. setting ?1? in one of the bce bits enables the control comparison for this bit 14.6.5.4 chr5-8 - bisync control character registers figure 66 shows a bisync control register format. the char field holds the pattern for the control character while bits 8-15 are used to control the GT-96100A behavior when the control character is recognized. figure 66: bisync control character register format 1 5 1 4 1 3 1 2 1 1 1 09876543210 char vbh i stx soh itt GT-96100A advanced communication controller 358 revision 1.0 the bisync control character programming recommendations for auto transparent mode and cpu con- trolled operation are shown in the following tables. table 341: bisync control character register format bits field name function initial value 7:0 char the control character to sync on note: bit 7 must be programmed according to the parity method in use. see table 340 . 0 8 reserved. 0 9 soh soh character 0 - normal mode. 1 - soh character. in auto transparent mode the characters following soh including stx are part of the bcc calculations. 0 10 stx stx character 0 - normal character. 1 - stx character. in auto transparent mode, an stx character is expected after the first dle in order to enter transparent mode. 0 11 itt ignore while receiving in text mode 0 - normal control character. 1 - ignore this character after entering text mode (i.e. after receiving syn- syn-stx/soh). 0 12 i interrupt 0 - no interrupt. 1 - generate interrupt upon receiving this char. 0 13 h hunt 0 - close buffer and maintain sync. 1 - close buffer and move to hunt state. 0 14 b bcc next 0 - close buffer. 1 - bcc is next. receive bcc and than close buffer. 0 15 v valid. 0 - entry is not valid. 1 - entry is valid. 0 GT-96100A advanced communication controller revision 1.0 359 14.6.5.5 chr9 - reserved this register is reserved. do not access this register in the bisync mode. table 342: auto transparent programming control character v b h i itt stx soh stx 1 1. ctl3 must be use to hold stx 100x110 soh 2 2. ctl4 must be use to hold soh 100x101 etx 111x000 itb 110x000 etb 111x000 enq 101x000 eot 101x100 nack 101x100 table 343: cpu controlled operation control character v b h i itt stx soh etx 111x000 itb 110x000 etb 111x000 enq 101x000 eot 101x100 nack 101x100 other entry other entry GT-96100A advanced communication controller 360 revision 1.0 14.6.5.6 chr10 - bisync event status register (esr) the esr register holds information on the transmit/receive channel condition. chr10 can be read by the cpu for channel condition resolution. some changes in the channel condition can generate maskable interrupts, as shown below. note: perr will be set in transparent mode during syn stripping when a non dle or syn character is received. this is a protocol violation. the receiver moves to hunt mode and a maskable interrupt is gen- erated. the received character is discarded. table 344: chxr10 - bisync event status register (esr), offset: 0x000a30, 0x008a30, 0x010a30, 0x018a30, 0x020a30, 0x028a30, 0x030a30, 0x038a30 (where x is channel 0 and 7) bits field name event 0 cts clear to send signal 1 1. interrupt is generated when signal is deasserted during transmit 1 cd carrier detect signal 2 2. interrupt is generated when signal is deasserted during receive 2 reserved 3 tidle tx in idle state 3 3. interrupt is generated upon entering idle state 5 rhs rx in hunt state 10:6 reserved 11 rlidl 1 = rx idle line 4 4. interrupt is generated upon change in line status 12 dpcs 1 = dpll carrier sense 15:13 reserved. 23:16 rcrn received control character n when the bisync receiver recognizes a control character it sets the corresponding rcrn bit. bit 16 (rcr1) corresponds to ctl1. bit 23 (rcr8) corresponds to ctl8. rcrn bits are cleared by writing ?1? to the bit. rcrn is set if the corresponding control character arrives, and both its valid bit and interrupt bit are also set (e.g., bit 16 will be set if ctl1 arrives, and both ctl1?s ?v? bit is set, and ctl1?s ?i? bit is also set.) GT-96100A advanced communication controller revision 1.0 361 14.7 uart mode 14.7.1 uart receive/transmit operation in uart mode an mpsc performs the following protocol functions: ? start/stop bit framing. ? programmable data lengths (5-8 bits). ? synchronous and asynchronous support. ? message oriented data support. ? parity detection and generation. ? frame error, noise error, break, and idle detection. ? support for hdlc over asynchronous control-octet transparency protocol. ? multidrop operation with address recognition of up to two different addresses. figure 67 shows a typical uart frame format. a frame with a start bit is followed by 5-8 data bits. the address and parity bits are optional. figure 67: typical uart frame at the end of a frame there are 1?2 stop bits before the transmitter can start to transmit the next frame. if there is nothing to transmit, a continuous ?1? is transmitted. this indicates that the line is idle. the GT-96100A?s uart samples each bit three times near its central point to define the bit value. a new start bit can be recognized only after the last stop bit sample is received. for example, at a 16x clock rate, the receiver can receive a start bit after a 9/16 bit time long stop bit. when in uart mode, the rdw bit in the mmcrx should be set to configure the mpscx data path to 8 bits. a uart transceiver can work in asynchronous or isochronous modes. 14.7.1.1 asynchronous mode in asynchronous mode, the dpll encoding must be set to rnz and the clock sampling rate is set to 8x, 16x, or 32x of the data rate. the dpll is synchronized by the falling edge of the start bit. if no error occurs, it maintains synchronization until the last bit in a frame is received. start bit add bit (optional) par bit (optional) stop bit data 5-8bbits GT-96100A advanced communication controller 362 revision 1.0 each bit is sampled three times around it?s middle point. the bit value is determined by a majority vote. this fea- ture helps to filter out noise from received data. 14.7.1.2 isochronous mode in isochronous mode, the dpll sampling rate will be 1x the data rate. the receive data must be synchronized to the receive clock. 14.7.2 sdmax command/status field for uart mode when an mpsc is in uart mode the command/status field in the corresponding sdmax descriptor has the following format: table 345: sdmax command/status field for uart mode bit rx - function tx - function 0 pe - parity error. last byte in buffer has parity error. reserved 1 cdl - cd loss ctsl - cts loss 2 reserved reserved 3 fe - framing error reserved 5:4 reserved reserved 6 or - data overrun reserved 8:7 reserved reserved 9 br - break received while receiving data into this buffer reserved 10 mi - max idle. buffer was closed due to max_idle timer expiration. note: when this bit is set, the status of bit 0 is disregarded. reserved 11 a - address. first byte in the buffer is an address. (valid only in multidrop mode, ?0? in point to point mode.) reserved 12 am - address match. this bit will be set to ?1? when a match occurred even if the v bit of the address is disabled. reserved 13 ct - the last byte in the buffer was precede by a transparency control octet. reserved 14 c - the last byte in a buffer is a user define control character. reserved 15 es - error summary es = pe || cdl || fe || or es - error summary es = ctsl 16 l - last l- last GT-96100A advanced communication controller revision 1.0 363 14.7.3 mpscx protocol configuration register (mpcrx) for uart mode figure 68: mpscx protocol configuration register (mpcrx) for uart mode 17 f - first f - first 18 reserved p - preamble. when set, the uart will send an idle preamble before buffer data. if data length is 0, only preamble idle will be send. 19 reserved a - address. when set, buffer content will be sent with address bit on. valid only in multidrop mode. 20 reserved ns - no stop bit. when set, data will be sent without stop bit. 22:21 reserved reserved 23 ei - enable interrupt ei - enable interrupt 29:24 reserved reserved 30 am - auto mode am - auto mode 31 o - owner o - owner table 345: sdmax command/status field for uart mode (continued) bit rx - function tx - function 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 098 76543210 base + 08 mpcr frz drt flc sbl cl um rzs iso GT-96100A advanced communication controller 364 revision 1.0 table 346: mpscx protocol configuration register (mpcrx) for uart mode, offset: 0x000a08 , 0x008a08, 0x010a08, 0x018a08, 0x020a08, 0x028a08, 0x030a08, 0x038a08 (where x is the port number 0 to 7) bits field name function initial value 5:0 reserved. 0 6 drt disable rx on tx. when drt is set to ?1? the rx path is closed during tx. this is useful in multidrop configurations when a user doesn?t want to receive its own frames 0 7 iso isochronous mode 0 - asynchronous mode. start and stop bits are expected. renc in the mmcrx should be programmed to nrz and rcdv should be programmed to x8, x16 or x32 mode. (x16 is recommended for most applications). 1 - isochronous mode. the receive bit stream is assumed to be synchro- nous to the receive clock. rcdv should be programmed to x1 mode. 0 8 rzs receive zero stop bit 0 - normal mode. at least one stop bit is expected. 1 - zero stop bit. the receiver continues reception when a stop bit is miss- ing. if a ?0? is received when stop bit is expected, this bit is considered a start bit. the fe (framing error) bit is set and the next bit to be received is considered to be data. 0 9 frz freeze tx 0 - restart tx after freeze (normal operation). transmission continues from the place it stopped. 1 - freeze tx at the end of the current character. 0 11:10 um uart mode 00 - normal mode. multidrop is disabled and idle line wake up is selected. a uart receiver wakes up after entering hunt mode upon receiving an idle character (all one character). 01 - multi drop mode. in multidrop mode, there is an additional address/ data bit in each character. upon receiving an address character, the uart receiver compares it to two 8-bit addresses stored in it?s channel registers. if a match occurs, the receiver transfers the address and the following char- acters into a new buffer. if there is a no match, the character is discarded and the receiver is set to the hunt mode. if none of the addresses is valid (v bit in both address register is set to ?0?), there is always a match and all the characters are transferred into the dram. addresses are always be placed in a new buffer (regardless of the v bit). the receiver receives characters until a new address is received, an abort character is received, an enter hunt command is issued, or until max idle counter expiration. upon max idle counter expiration, the receiver is set to the hunt mode. 10 - reserved. 11 - reserved. 0 GT-96100A advanced communication controller revision 1.0 365 note: when cd* is deasserted during frame reception uart behavior is different for multidrop and normal modes. in normal mode the uart hunts for an idle character (hunting starts when cd* is asserted again) before receiving valid start bit. in this mode, transmitting from a GT-96100A model to another should be with the ?p? bit in the buffer descriptor set. in multidrop mode, the uart receiver hunts for a start bit as soon as cd* is asserted again. 14.7.4 uart stop bit reception and framing error the uart receiver always expects to find a stop bit at the end of a character. if no stop bit is detected, the fram- ing error (fe) bit is set in the receive descriptor. after a framing error, the reception process is controlled by the rzs and um bits in the uart mpcrx. the various options are summarized in the table bellow. 13:12 cl character length 00 - 5 data bits 01 - 6 data bits 10 - 7 data bits 11 - 8 data bits 01 14 sbl stop bit length 0 - one stop bit 1 - two stop bits 0 15 flc flow control 0 - normal mode. the ctsm bit in the mmcrx determines the cts* pin behavior. 1 - asynchronous mode. when cts* is negative, transmission stops at the end of the current character. when cts* is asserted again the transmission starts from the place it stopped. no cts* lost is reported. line is idle (mark) during cts* deassertion period. 0 31:16 reserved 0 table 347: uart stop bit reception and framing error um rzs operation break recognition 00 0 go to hunt after missing a stop bit. the receiver is enabled after receiving a new idle char. single break 00 1 the receiver tries to synchronize itself. the missing stop bit is considered as the following start bit and the reception process continues. two break sequence table 346: mpscx protocol configuration register (mpcrx) for uart mode, offset: 0x000a08 , 0x008a08, 0x010a08, 0x018a08, 0x020a08, 0x028a08, 0x030a08, 0x038a08 (where x is the port number 0 to 7) (continued) bits field name function initial value GT-96100A advanced communication controller 366 revision 1.0 01 0 goes to hunt after missing stop bit. the receiver is enabled after receiving new address character. single break 01 1 the receiver tries to synchronize itself. the missing stop bit is considered as the following start bit and the reception process continues. two break sequence table 347: uart stop bit reception and framing error (continued) um rzs operation break recognition GT-96100A advanced communication controller revision 1.0 367 14.7.5 channel registers (chxrx) for uart mode the mpscx channel registers (chxrx) are protocol dependent. figure 69 shows the chxrx format in uart mode. figure 69: channel registers (chxrx) for uart mode unless otherwise specified: ? ?1? means set. ? ?0? means unset. ? ?0? is the default value after reset. 14.7.5.1 chr1 - uart break/stuff register (ubsr) the uart break/stuff register has two fields: break count (brk)(chr1[23:16]) and control stuff character (tcs) (chr1[7:0]). with the brk field, the uart transmitter will starts to transmit break characters after receiving an abort com- mand. the number for the break character to send is programmed into the brk field. for example, when brk equals ?0?, no break character is transmitted. when brk equals ?1?, one break charac- ter is transmitted. a break character is a character with all ?0?s including it?s stop bit. upon issuing a tcs command, the transmitter sends a tcs character after the current transmitting character. this allows a transmitter to bypass the normal pipeline when a special control character must be send (e.g. xon/ xoff). upon receiving a break character, the uart stops the reception process and moves to the hunt state. in a point to point configuration, the receiver is hunting for a new idle character. in a multidrop configuration, the receiver hunts for a new address character. 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 base +0c base + 10 chr1 - ubsr chr2 - cr base + 14 chr3 - mir chr10 - esr base + 18 chr4 - cfr base + 1c chr5 - ctlr1 base + 20 chr6 - ctlr2 base + 24 chr7 - ctlr3 base + 28 chr8 - ctlr4 base + 2c chr9 - adr tcs ctl4 ctl6 ctl5 ctl3 a brk eh a ctl2 ctl1 base + 30 event ctl8 ctl7 ad2 ad1 tcs crd rpm tpm rev tev mir cfr v v GT-96100A advanced communication controller 368 revision 1.0 when the uart is in rzs=0 mode after receiving a break sequence, the descriptor is closed with br bit (bit 9) set. in addition, a ?break descriptor? also has the fe bit (bit 3) set and, if in odd parity, the pe bit (bit 0) is also set. when the uart in rzs=1 mode, two consecutive break sequences are needed for proper break recognition. the first break character is not recognized. instead, the uart receiver closes the descriptor with the fe bit (bit 3) set and, if in odd parity, the pe bit (bit 0) will also be set. the second break will be recognized as a break and a descriptor will be closed with the br bit (bit 9) set. in addition, a ?break descriptor? will also have the fe bit (bit 3) set and, if in odd parity, the pe bit (bit 0) will also be set. 14.7.5.2 chr2 - command register (cr) table 348: chxr2 - command register (cr), offset: 0x000a10, 0x008a10, 0x010a10, 0x018a10, 0x020a10, 0x028a10, 0x030a10, 0x038a10 (where x is channel 0 and 7) bits field name function initial value 0 reserved. 0 1 tev tx enable vertical redundancy check 0 - vrc (parity) is disabled. 1 - vrc is enabled. 0 3:2 tpm transmit parity mode 00 - odd 01 - low (always 0) 10 - even 11 - high (always 1) 0 6:4 reserved. 0 7 a transmit abort aborts the transmission immediately (on byte boundaries) and goes to idle. the descriptor is not closed or incremented. after receiving an abort command, the GT-96100A halts the transmit pro- cess and starts sending a break sequence according to the brk field in chr1. note: command is not synchronized to byte. 0 8 reserved. 0 9 tcs transmit tcs character. the tcs character is transmitted after the current transmitted character. the transmitter then continues with the normal tx sequence. the tcs command can be used to send out of band characters such as xoff and xon. 0 16:10 reserved. 0 17 rev rx enable vertical redundancy check 0 - vrc (parity) is disabled. 1 - vrc is enabled. 0 GT-96100A advanced communication controller revision 1.0 369 19:18 rpm receive parity mode. 00 - odd 01 - low (always ?0?) 10 - even 11 - high (always ?1?) 0 22:20 reserved. 0 23 a receive abort abort receive immediately and go to idle. the descriptor is not closed or incremented. the processor must issue a enter hunt command after an abort command in order to enable reception. the a bit is cleared upon entering idle state. 0 24 reserved. 0 25 crd close rx descriptor when the cpu issues a crd command the current receive descriptor is closed and subsequent received data is dma?d into a new buffer. if there is no active receive process, no action takes place. the GT-96100A clears the crd bit upon closing the buffer status. 1 0 30:26 reserved. 0 31 eh enter hunt upon receiving an enter hunt command, the receive machine moves to a hunt state and continuously searches for an opening character. an opening character is considered an idle char in point to point mode (um=00) or a matched address in multidrop mode. the eh bit is cleared upon entering a hunt state. 0 n/a td transmit demand fetch a descriptor and start transmission. issued through the sdmax command register . n/a stop stop complete frame transmission and stop. (go to idle). issued through the sdmax command register. 1. usually, it takes a few cycles from the time the crd bit is closed until the sdmax actually closes the buffer. the sdmax generates a maskable interrupt when closing a buffer if programed to do so. table 348: chxr2 - command register (cr), offset: 0x000a10, 0x008a10, 0x010a10, 0x018a10, 0x020a10, 0x028a10, 0x030a10, 0x038a10 (where x is channel 0 and 7) bits field name function initial value GT-96100A advanced communication controller 370 revision 1.0 the et bit in the main configuration register must be set to ?1? before issuing any of the following commands: ? transmit demand ? stop transmission ? transmit tcs character ? abort transmission the er bit in the main configuration register must be set to ?1? before issuing any of the following commands: ? enter hunt ?close rx descriptor ? abort reception when the et or er bits are deasserted, the mpscx transmit/receive channel is in low power mode (no clock). note: issuing one of the above commands in this state leads to unpredictable results. the crcm in the mmcr must be set to 011 for lrc/vrc mode. 14.7.5.3 chr3 - max idle register (mir) this 16-bit value (chr3[15:0]) defines the number of idle characters the receiver waits before it closes a descriptor and a maskable interrupt is generated. when set to ?0?, the counter is disabled. the counter is preloaded every time a non-idle character is received. 14.7.5.4 chr4 - control filtering register (cfr) bits 7:0 of the cfr register are the bit comparison enable bits. setting a ?1? in one of the bce bits enables the control comparison for this bit. 14.7.5.5 chr5-8 - uart control character registers figure 70 shows a uart control register format. the char field holds the pattern for the control character while bits 8-15 are used to control the GT-96100A?s behavior when the control character is recognized. figure 70: uart control character register format 1 5 1 4 1 3 1 2 1 1 1 09876543210 char vr co int GT-96100A advanced communication controller revision 1.0 371 14.7.5.6 chr9 - address register (adr) chr9 holds the uart addresses for multidrop operation. the GT-96100A uart supports up to 2 addresses. upon receiving an address, the uart transfers the previous frame status to the sdma. this causes the sdma to close the previous frame descriptor and to locate the address in a new buffer. there are two modes for address recognition operation. the first mode, setting of ?1?, allows the address and fol- lowing characters to be transferred to the sdma only if there is a match. the second mode, setting of ?0?, allows all frames to be passed to the sdma. the cpu can use the am bit in the last frame descriptor to check if a match occurred. 14.7.5.7 chr10 - uart event status register (esr) the esr register holds information on the transmit/receive channel condition. chr10 can be read by the cpu for channel condition resolution. some changes in the channel condition can generate maskable interrupts, as shown in table 350 . table 349: uart control character register format bits field name function reset value 7:0 char the control character to sync on. 0 11:8 reserved. 0 12 int interrupt 0 - no interrupt. 1 - generate interrupt upon receiving this char. 0 13 co control octet (iso 3309 control octet) upon receiving a control octet, the control octet is discarded and the 6th bit (i.e. bit 5 in chr5) of the following octet is complemented. the current buffer is closed with the co bit asserted. note: when the co bit is set, the char field must be programmed with ?10111110? in order to be iso-3309 compatible. 0 14 r reject 0 - receive character and close the buffer. 1 - reject character. the character is discarded, the buffer is closed and a maskable interrupt is generated. 0 15 v valid. 0 - entry is not valid. 1 - entry is valid. 0 GT-96100A advanced communication controller 372 revision 1.0 14.8 transparent protocol in transparent mode, the GT-96100A does not perform any protocol dependent data processing. however, it gives the processor hardware assistance for bit reception, using the GT-96100A?s powerful sdma engines, and some assistance in synchronization, interrupt generation, and frame construction. the cpu also uses the built-in crc engine for crc generation and checking. in any case, crc bits are transferred into mem- ory for cpu use. in transparent mode, the channel is fully configured from the mmcrx and no mode is defined by the channel registers. a transparent channel is synchronous.if it is not serviced on time, underrun and overrun errors can occur. table 350: chr10 - uart event status register (esr), offset: 0x000a30, 0x008a30, 0x010a30, 0x018a30, 0x020a30, 0x028a30, 0x030a30, 0x038a30 (where x is channel 0 and 7) bits field name event 0 cts clear to send signal 1 1. interrupt is generated when signal is deasserted during transmit. 1 cd carrier detect signal 2 2. interrupt is generated when signal is deasserted during receive. 2 reserved. 3 tidle tx in idle state 3 3. interrupt is generated upon entering idle state. 4 reserved. 5 rhs rx in hunt state 6 reserved. 7 rls rx line status 10:8 reserved. 11 rlidl 1 = rx idle line c 15:12 reserved. 23:16 rcrn received control char n when the uart receiver recognizes a control character it sets the corresponding rcrn bit. (bit 16 (rcr1) corresponds to ctl1... bit 23 (rcr8) corresponds to ctl8). rcrn bits are cleared by write a 1 to the bit. GT-96100A advanced communication controller revision 1.0 373 the receiver can use external sync using the cd* input or synchronize itself on a sync sequence according to the rsyl bits in the mmcrx. GT-96100A advanced communication controller 374 revision 1.0 14.8.1 sdmax command/status field for transparent mode when an mpsc is in transparent mode the command/status field in the corresponding sdmax descriptor has the following format: table 351: sdmax command/status field for transparent mode bit rx - function tx - function 0 ce - crc/lrc error reserved. 1 cdl - cd loss ctsl - cts loss 2 de - decoding error reserved. 3 reserved. reserved. 4 reserved. reserved. 5 reserved. reserved. 6 or - data overrun ur - data underrun 14:7 reserved. reserved. 15 es - error summary es = ce || cdl || de || or es - error summary es = ctsl || ur 16 l - last l - last 17 f - first f - first 21:18 reserved. reserved. 22 reserved. gc - generate bcc/lrc. 23 ei - enable interrupt ei - enable interrupt 29:24 reserved. reserved. 30 am - auto mode am - auto mode 31 o - owner o - owner GT-96100A advanced communication controller revision 1.0 375 14.8.2 channel registers (chxrx) for transparent mode figure 71: channel registers (chxrx) for transparent mode unless otherwise specified: ? ?1? means set. ? ?0? means unset. ? ?0? is the default value after reset. 14.8.2.1 chr1 - sync register (synr) the sync register holds the synchronization for the channel receiver. after reset it holds the value of 7e in the sync field. the user should right the appropriate values before enabling the rx/tx machines. there are two basic synchronization options for a transparent channel: transparent mode synchronization and transmitter synchronization. the transparent mode synchronization has two synchronization options, selected by setting rsyl[24:23] in the mmcrx. the transparent mode synchronization has two synchronization options. they are also selected by setting the rsyl [24:23] bits in the mmcrx. note: for more information about setting rsyl[24:23], see table 324 . 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 0987654 3210 base +0c base +10 chr1 - synr chr2 - cr base + 14 chr3 chr10 - esr base + 18 chr4 base +1c chr5 base + 20 chr6 base + 24 chr7 base + 28 chr8 base + 2c chr9 sync a eh a base +30 event crd v GT-96100A advanced communication controller 376 revision 1.0 there are two mode of transmit synchronization in transparent mode. they are selected by setting tsyn[12} in the mmcrx, see table 322 . table 352: transparent mode synchronization options synchronization option description external synchronization (rsyl = ?00?) the receiver starts to receive data whenever cd* is asserted and stops receiving data when cd* is deasserted (if cdm=0) or when the cpu issues an enter hunt command. sync hunt rsyl = ?01?, ?10?, or ?11? (nibble, byte or two bytes sync) the receiver hunts for the sync pattern, as defined by rsyl. when the synch pattern is recognized, the receiver starts to receive data. the receive process stops when cd* is deasserted and cdm=0 or when the cpu issues an enter hunt command. if bit 15 is set, there is no transfer of the sync characters to the receiver. the syncs are stripped until the first data character is received, and are not calculated in the packet crc. if bit 15 is reset, sync characters that appear after the sync pattern is recognized are regarded as data. on the transmitter side, in sync hunt mode, two sync characters are always sent at the beginning of a frame. note: when rsyl equals 01, the sync pattern is defined by bits [7:4] of the sync register. table 353: transmitter mode synchronization options synchronization option description tsyn = 0 synchronization is achieved whenever cts* is asserted. tsyn=1 synchronization is achieved after receiver synchronization and cts* is asserted. the transmitter always starts to transmit on the receive byte boundaries. in external synchronization, when cts* is asserted, the transmitter starts to transmit 8 bits after cd* assertion. in sync hunt mode, when cts* is asserted, the transmitter starts to transmit 8 bits after sync recognition. if cts* is deasserted after the receiver gains synchronization, the transmitter waits to the byte boundary before it starts to transmit. GT-96100A advanced communication controller revision 1.0 377 14.8.2.2 chr2 - command register (cr) the et bit in the main configuration register must be set to ?1? before issuing any of the following commands: ? transmit demand ? stop transmission ? abort transmission table 354: chxr2 - command register (cr), offset: 0x000a10, 0x008a10, 0x010a10, 0x018a10, 0x020a10, 0x028a10, 0x030a10, 0x038a10 (where x is channel 0 and 7) bits field name function initial value 6:0 reserved reserved. 0 7 a abort transmission aborts the transmission immediately (on byte boundaries) and goes to idle. the descriptor is not closed or incremented. note: command is not synchronized to byte. 0 22:8 reserved reserved. 0 23 a abort reception abort receive immediately and go to idle. the descriptor is not closed or incremented. the processor must issue an enter hunt command after an abort command in order to enable reception. the a bit is cleared upon entering idle state. 0 24 reserved reserved. 0 25 crd close rx descriptor when the cpu issues a crd command the current receive descriptor is closed and the following received data is sdma?d into a new buffer. if there is no active receive in progress, no action takes place. 0 30:26 reserved reserved. 0 31 eh enter hunt upon receiving an enter hunt command, the receive machine moves to a hunt state and continuously searches for an opening sync or an external sync. if the enter hunt command is received during a frame reception, the current descriptor is closed with a crc error. the eh bit is cleared upon entering a hunt state. 0 n/a td transmit demand fetch a descriptor and start transmission. issued at sdmax command register. n/a stop stop complete frame transmission and stop. (go to idle). issued at sdmax command register. GT-96100A advanced communication controller 378 revision 1.0 the er bit in the main configuration register must be set to ?1? before issuing any of the following commands: ? enter hunt ?close rx descriptor ? abort reception when the et or er bits are deasserted, the mpscx transmit/receive channel is in low power mode (no clock). note: issuing one of the above commands in this state leads to unpredictable results. 14.8.2.3 chr10 - transparent event status register (esr) the esr register holds information on the transmit/receive channel condition. chr10 can be read by the cpu for channel condition resolution. some changes in the channel condition can generate maskable interrupts, as shown table 355 . table 355: chr10 - transparent event status register (esr), offset: 0x000a30, 0x008a30, 0x010a30, 0x018a30, 0x020a30, 0x028a30, 0x030a30, 0x038a30 (where x is channel 0 and 7) bits field name event 0 cts clear to send signal 1 1. interrupt is generated when signal is deasserted during transmit 1 cd carrier detect signal 2 2. interrupt is generated when signal is deasserted during receive 2 reserved. 3 tidle tx in idle state 3 3. interrupt is generated upon entering idle state 4 reserved. 5 rhs rx in hunt state 11:6 reserved. 12 dpcs 1 = dpll carrier sense 15:13 reserved. 23:16 rcrn received control character n when the transparent receiver recognizes a control character it sets the corresponded rcrn bit (bit 16 (rcr1) corresponds to ctl1... bit 23 (rcr8) correspond to ctl8). rcrn bits are cleared by writing ?1? to the bit. GT-96100A advanced communication controller revision 1.0 379 15. f lex tdm u nits (ftdm) there are four flextdm units (also called time slot assigners) in the GT-96100A. each unit is capable of sup- porting iom-1/2 (gci), pcm highway, t1/cept lines, as well as other proprietary time slot assigned buses. the time slot assignment is configured by programming an internal dual port ram (dpram). this dpram supports static and dynamic configurations. the dpram based design provides the flexibility to program the flextdm to any of the common time slot buses (i.e. gci, pcm) or to a proprietary bus. the flextdm unit consists of a transmit and a receive section. each has a dedicated 256 entry dual port ram. figure 72 shows a block diagram of a flextdm unit. figure 72: flextdm architecture rx dpram 256x27 tx dpram 256x27 rxd mux mpsc rx bus mpsc tx bus aux channels a and b rd wr ctl rsync clk ctl rclk mask 1/2 mask txd txd_oe ctl rd wr mux aux channels a and b clk ctl tclk 1/2 tsync strb toclk GT-96100A advanced communication controller 380 revision 1.0 15.1 flextdm architecture the flextdm architecture is based on two dual-port ram (dpram) arrays. one ram array is for receiving and one is for transmitting. the frame structure of a time slot assigned bus is configured by programming this dpram. the flextdm incorporates two auxiliary channels: auxa and auxb. these channels are customized for the iom monitor and c/i channels. the eight mpscs and two auxiliary channels are time multiplexed on the txd and rxd lines using two dedi- cated muxes. the mux select lines are controlled through dpram programming. a mpsc connected to a flextdm gets it?s receive and transmit signals from the flextdm. the actual bit rate of the mpsc is defined by the flextdm programming and the time slots that are assigned to this mpsc. the flextdm supports independent transmit and receive clocks and frame syncs. either 1x or 2x input clocks are allowed (the 2x clock is required for iom bus interface). selection of clock edges (rising/falling) for frame sync and data is supported as well. 15.2 flextdm dpram the flextdm dpram is a 256x27 dual port ram array that controls the flextdm behavior. the dpram can be configured dynamically during flextdm operation. table 356 shows the flextdm dpram field assignments. table 356: flex tdm dpram entry bits field name function reset value 26 ftint flextdm interrupt an interrupt is generated if ftint bit is set in the current entry and reset in the last tdm entry that was executed. x 25 l last entry in frame the tdm read pointer returns to entry 0 or entry 128 (address 0 or 128 of the tdm dpram) after reading this entry. control of which entry is executed next - either 0 or 128 - is done through r2half and t2half bits in tcr (see section 15.4 ?flextdm configuration register (tcr)? on page 384 ). x 24:23 rpt number of times entry is repeated before moving to the next entry. the flextdm repeats execution of this entry according to the value pro- grammed in rpt. 1 00 - entry not repeated (i.e. it is executed once). 01 - entry repeated once. 10 - entry repeated twice. 11 - entry repeated three times (i.e. it is executed four times). x 22:21 reserved. x GT-96100A advanced communication controller revision 1.0 381 20:19 strb this field controls the tdstrb output of the tdm. 00 - 0 01 - z (tri-state) 10 - toggle (strobe state is inverted every cycle this entry is executed) 11 - 1 note: the flextdm provides a single external strobe signal, which is shared between the receive and transmit sections. the strobe pin is driven according to the logical or of the internally generated strobe signals. for example, if transmit strobe is z and receive strobe is 0, external strobe will be 0. if transmit strobe is 1 and receive strobe is 0, external strobe will be 1. x 18 b byte defines byte/bit resolution for this entry. 0 - bit. data width associated with this entry is 1 bit. 1 - byte. data width associated with this entry is 1 byte (8 bits). note: when b=1, indicating byte resolution, the dpram entry is exe- cuted 8 times (once for each bit in the byte). 1 x 17:13 reserved. x 12:8 ch channel select controls which of the serial controllers is assigned to the current data group. 00000 - mpsc0 00001 - mpsc1 00010 - mpsc2 00011 - mpsc3 00100 - mpsc4 00101 - mpsc5 00110 - mpsc6 00111 - mpsc7 11110 - auxa 11111 - auxb note: ch values not listed above are reserved and are not to be used. x table 356: flex tdm dpram entry (continued) bits field name function reset value GT-96100A advanced communication controller 382 revision 1.0 7:0 mask mask pattern for the current data. definition of this field is dependent on b (byte/bit) setting. b=1 (byte mode) in byte mode each bit in the mask field defines the mask for the corre- sponding bit in the data. ? 1 - tdm transmit data is driven out, receive data is processed nor- mally. ? 0 - tdm transmit data is not driven out (transmit output is tri- stated), receive data is ignored. b=0 (bit mode) in bit mode only bits 5:0 are valid. bits 7:6 must be set to ?0?. bits 1:0 define the mask for the current bit: ?00 - z transmit output is tri-state. receive data is ignored. ?01 - 0 transmit output is forced low. receive data is ignored. ?10 - d transmit data driven out. receive data is processed normally. ? 11 - 1 (transmit output is forced high, receive data is ignored) bit 2 serves as the d channel bit. setting this bit to ?1? marks this time slot as a d channel time slot. this bit identifies the mpsc to which the tdm must assert or de-assert the internal cts signal based on the recent sampled value of the dgrant bit (see below). ? if dgrant is sampled low, cts is asserted. ? if dgrant is sampled high, cts is deasserted. ? if dgrant is deasserted while a d channel frame is being transmit- ted, the mpsc connected to the d channel stops transmission (due to cts lost) and initiates a collision resolution procedure. bit 3 - dgrant/dreq in a received frame, this bit serves as the dgrant bit. an iom (gci) phy uses this bit to signal the GT-96100A that it has access to the d channel. in a transmit frame, it serves as the dreq bit. the GT-96100A drives the dreq bit to ?0? when sending data on the d channel. when not sending data on the d channel, dreq is driven according to the value programmed in mask[1:0] bits. bit 4 identifies the current bit as the iom-2 mx bit. the GT-96100A recog- nizes an inactive-to-active transition of received mx bit as an indication that valid iom-2 monitor data is driven by the phy. bit 5 identifies the current bit as the iom-2 mr bit. the GT-96100A recog- nizes an inactive-to-active transition of received mr bit as an indication that iom-2 monitor data, sent by the GT-96100A, have been sampled by the phy. x table 356: flex tdm dpram entry (continued) bits field name function reset value GT-96100A advanced communication controller revision 1.0 383 notes: when the flextdm is disabled, the cpu accesses the dpram for both reads and writes. when the flextdm is enabled, the flextdm dpram is write only. after reset the dual port ram entries are undefined. users must explicitly program the required entries in order to ensure correct and consistent system operation. 15.3 flextdm programing modes after enabling the flextdm, there are two ways the user can dynamically program the dpram: single array mode and split array mode. in single array mode, the flextdm read pointer always returns to entry 0 after receiving a sync or reading the last entry (entry with l bit set). the entire range of 256 entries is available for programing a tdm frame. the user can dynamically make changes in the dpram but precautions must be made not to write to the same address from which the flextdm is reading. this can be done by checking the read pointer before accessing the dpram array. in split array mode, the tdm frame is limited to 128 dpram entries. the user programs the flextdm frame in entries 0-127 and enables the flextdm. when a change in programming is needed, the user first programs the new frame in entries 128-255 and than sets the r2half (read as ?return to half?) bit in the tcr. when the next sync or last entry occurs, the flextdm starts processing the frame as programmed in entries 128-255. the user can then re-program entries 0-127. this process of switching between one half of the dpram and the other half simplifies on-the-fly dpram changes. note: if a frame structure is changed (e.g. a change in frame length) while the flextdm is enabled, the flextdm can lose synchronization. this can lead to a cd lost error and a cts lost error for all chan- nels that are connected to the flextdm. 1. the total number of times that a dpram entry is actually repeated is set by both the rpt (bits 24:23) and b (bit 18) fields. th e range is 1 (b=0, rpt=00) to 32 (b=1, rpt=11). GT-96100A advanced communication controller 384 revision 1.0 15.4 flextdm configuration register (tcr) table 357: flextdmx configuration register (tcr), offset: 0x008b08, 0x018b08, 0x028b08, 0x038b08 (where x is flextdm 0 to 3) bits field name function reset value 6:0 reserved 7 tddchg tdm delay for d_channel grant, 0-low priority 1-high priority 1 10:8 tdtt tdm delay for transparent transmit tdtt must be set to ?101? for proper operation. 101 13:11 tdtr tdm delay for transparent receive tdtr must be set to ?100? for proper operation. 100 14 ttm tdm transparent mode ttm must be set to ?0? for proper operation. 0 15 rr2half receive return to half. this bit is used for dynamic programming of the tdm receive frame. 0 - return to 0. after sync or last, the flextdm receive read pointer returns to entry 0 in the rx dpram. 1 - return to 128. after sync or last, the flextdm receive read pointer returns to entry 128 in the rx dpram. 0 16 tr2half transmit return to half used for dynamic programming of the tdm transmit frame. 0 - return to 0. after sync or last, the flextdm transmit read pointer returns to entry 0 in the tx dpram. 1 - return to 128. after sync or last, the flextdm transmit read pointer returns to entry 128 in the tx dpram. 0 19:17 tm tdm mode 000 - pcm 001 - reserved 010 - iom1 011 - reserved 100 - iom2-te 101 - reserved 110 - iom2-lc 111 - reserved 0 GT-96100A advanced communication controller revision 1.0 385 20 se sync edge (for trsync and ttsync) 0 - sync signals are sampled on falling edge of the clock. 1 - sync signals are sampled on rising edge of the clock. 0 21 de driving edge. 0 - transmit data is sent on rising edge, receive data is sampled on fall- ing edge of the clock. 1 - transmit data is sent on falling edge, receive data is sampled on ris- ing edge of the clock. 0 22 stz set tx to zero when set, the tdm transmit output (ttxd) is forced to zero until a serial clock is available. (iom-2 mode) 0 23 crt common receive and transmit pins 0 - separate receive and transmit pins. 1 - common receive and transmit pins. the transmit section of the flextdm uses the flextdm?s rx clock and rx sync signals. in this mode, ttclk and ttsync pins are used as general purpose pins. 0 24 clkdv divide clk by two 0 - normal (1x) clock mode 1 - double (2x) clock mode input clock is twice the bit clock. (iom-2 mode) 0 26:25 tsd transmit sync delay specifies the delay (in number of bits) between transmit sync and the first bit of the transmit frame. 00 - no bit delay (iom-2 mode). 01 - 1-bit delay 10 - 2-bit delay 11 - 3-bit delay 0 28:27 rsd receive sync delay specifies the delay (in number of bits) between receive sync and the first bit of the receive frame. 00 - no bit delay (iom-2 mode) 01 - 1-bit delay 10 - 2-bit delay 11 - 3-bit delay 0 table 357: flextdmx configuration register (tcr), offset: 0x008b08, 0x018b08, 0x028b08, 0x038b08 (where x is flextdm 0 to 3) (continued) bits field name function reset value GT-96100A advanced communication controller 386 revision 1.0 15.5 flextdm synchronization after enable, the flextdm needs to receive one received sync to achieve synchronization. until synchronization is achieved, the flextdm transmit and receive paths are disabled. after gaining synchronization, the flextdm always predicts when the next sync is expected. if the sync signal is not asserted when expected, the flextdm executes a synchronization lost procedure and a maskable interrupt is generated. all the mpscs that are connected to the flextdm experience a cd loss and a cts loss and all the transmit and receive processes are halted until synchronization is gained again. 30:29 tdiag tdm diagnostic 00 - normal operation the received input is connected to the flextdm receive pin (trxd) and transmit output is connected to the flextdm transmit pin (ttxd). 01 - echo tdm receive input is echoed on tdm output with one clock delay. the received bit stream is processed normally according to dpram program- ming. 10 - loopback transmit data is driven on tdm output, as in normal operation, and is also connected internally to the tdm receive line. the received bit stream is processed normally according to dpram programming. trans- actions on trxd are not seen by the flextdm. 11 - internal loopback (transmit output is inactive) tdm transmit output is internally connected to the tdm receive input. this mode is useful for tdm loopback testing without affecting the exter- nal lines. note: proper operation of the echo and loopback modes requires that an identical clock is supplied to the tdm?s transmit and receive sections. if a tdm entry in the dpram is in byte mode (bit 18,?b? is set to 1) and configured for a mpsc channel in trans- parent mode, bits 6 and 7 must never be masked simulta- neously. for example, a mask (bits 7:0 of the tdm entry) of 0b00xx xxxx (where x means ?don?t care?), dpram entry for mpsc channel in transparent mode is not allowed in byte mode. 0 31 ten enable flextdm 0 - flextdm disabled. transmit output is z. 1 - flextdm enabled. 0 table 357: flextdmx configuration register (tcr), offset: 0x008b08, 0x018b08, 0x028b08, 0x038b08 (where x is flextdm 0 to 3) (continued) bits field name function reset value GT-96100A advanced communication controller revision 1.0 387 15.6 iom (gci) mode the gci bus, also known as the iom-2 bus, is a super set of an older bus known as iom-1. while iom-1 is well suited for nt applications, it lacks the lapd d channel collision resolution support which is crucial for te implementation where multiple accesses to the d channel are allowed. the GT-96100A?s flextdm supports both the iom-1 and iom-2 frame structures. figure 73 depicts various iom frame struc- tures. figure 73: typical iom structures 15.6.1 iom-1 frames an iom-1 frame is constructed from two 8-bit b channels, one 2-bit d channel, a monitor channel, and a c/i channel. the monitor channel is used to transfer data between the cpu and an isdn phy device. this channel is also used for phy chip programing and layer-2 message transferring. the mr and mx bits are used to control the data transfers on the monitor channel. the c/i channel is used to transfer layer-1 messages between the cpu and the phy chip. in iom-1 mode no d channel control is supported and the d channel is assumed to be always granted. this mode can be used when interfacing phy chips such as the siemens peb-2081 and peb-2086. b1 monitor b2 c/i d2 d1 mr mx iom1 channel 0 iom2-te channel0 iom2- lc dcl 512khz dcl 4096hz dcl 1536khz fsc fsc fsc channel 1 channel 2 channel1 channel2 channel3 channel4 channel5 channel6 channel7 GT-96100A advanced communication controller 388 revision 1.0 15.6.2 iom-2-te frames an iom-2-te frame consists of three iom channels (channels 0,1,2). the c/i channel of the third sub-frame (i.e. iom channel 2) is used for tic bus applications. the tic bus is used by the phy device to grant d channel access. usually, bit 4 of c/i channel 2 is used as the d channel request/ grant bit. however, this is programmable in the GT-96100A and it is possible to specify any desired bit as the request/grant bit. the GT-96100A fully supports iom-2-te frames. in iom-2-te mode, the GT-96100A handles the d channel req/gnt protocol by itself. the GT-96100A accesses the d channel only when the received dgrant bit is asserted low. the GT-96100A drives the dreq bit to ?0? when sending data over the d channel. otherwise, it drives the value programed in mask[1:0] bits (see table 356 for more information). 15.6.3 iom-2-lc frames the iom-2 line card frame is used to connect up to eight isdn devices on the same card. an iom-2-lc frame consists of eight iom channels. the GT-96100A can be programmed to access any one of the iom channels. the monitor and c/i channels refer to the selected iom channel. however, other mpscs can be used to access other time slots in the iom-2-lc frame. 15.7 pcm highway mode this is a free programming mode where each mpsc can be connected to any time slot in the programed frame. 15.8 data rate adoption since it is capable of accessing each bit of the serial tdm stream separately, the flextdm supports data rate adoption. the flextdm dpram allows programmable routing of each bit (or byte) in the data to any of the mpscs and supports masking of bits which are to be ignored. the clock pulse associated with a masked bit is ?stolen? from the mpsc (or aux channel). thus, the serial controller is clocked at an effective rate that is appropriate for the logical data stream. 15.9 flextdm auxiliary channels a and b the auxiliary channels were designed to support the iom-2 monitor and c/i channels. these are simple channels accessible by reading and writing 8 bit registers. GT-96100A advanced communication controller revision 1.0 389 15.9.1 auxiliary channel a auxiliary channel a is used to access the monitor channel. the GT-96100A uses the iom mx and mr bits for interfacing to this channel. figure 74: auxiliary channel a control registers the cpu writes new data to the ata register and sets the v bit (bit 15) to 1. the GT-96100A loads the data into the channel a transmit shift register and clears the v bit. the auxiliary channel a transmitter will constantly transmit the contents of the ata to the monitor channel when enabled. a maskable interrupt will be generated when the mr bit in the receive frame changes from ?1? to ?0?, indicating the phy chip had received the transmit- ted byte. when the transmit flextdm loses synchronization (i.e. when the sync signal is asserted not where expected), the auxiliary channel a transmitter flushes its shift register and stops its transmit process. the transmit process restarts when the flextdm regains synchronization. the channel a receiver writes new data to the ara register and sets the v bit. the GT-96100A clears the v bit when the cpu reads the ara register. the auxiliary channel a receiver generates an interrupt whenever the mx bit in the received iom frame changes from ?1? to ?0?, indicating that there is new data in the ara register. when the receive flextdm loses synchronization, the auxiliary channel a receiver flushes it?s shift register and stop its receive process. the receive process restarts when the flextdm regains synchronization. the ara con- tents are not affected by synchronization lost. table 358 illustrates a typical monitor channel handshaking process. data 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 v ata data v ara GT-96100A advanced communication controller 390 revision 1.0 15.9.2 auxiliary channel b channel b is used to interface to the 32kbps c/i channel. the c/i channel is used to transfer 4-bit layer-1 com- mands between the cpu and the phy chip. a command is considered valid after it is received twice (i.e. after receiving 8 bits). figure 75: channel b control register the cpu loads atb with the data it wants to transmit and sets the v bit to 1. auxiliary channel b transmitter loads the new data into its internal shift register, clears the v bit and generates a maskable interrupt. the data is transmitted constantly until new data is loaded. table 358: monitor channel handshaking process monitor channel mx outgoing frame mr incoming frame interrupt mx incoming frame mr outgoing frame interrupt ff 1 1 1 1 ff 1 1 1 1 1st byte 0 1 0 1 rx 1st byte 0 0 tx 0 0 2nd byte 1 0 1 0 2nd byte 0 0 0 0 rx 2nd byte 0 1 0 1 2nd byte 0 0 tx 0 0 ff 1 0 1 0 ff 1 0 1 0 ff 1 1 1 1 ff 1 1 1 1 ff 1 1 1 1 ff 1 1 1 1 data 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 v atb data v arb GT-96100A advanced communication controller revision 1.0 391 note: the c/i channel messages are 4 bits wide. the message must be duplicated to create an 8-bit word, which is written to the 8-bit atb register. when the transmit flextdm loses synchronization (i.e. when the sync signal is asserted not where expected), the auxiliary channel b transmitter flushes its shift register and stop its transmit process. the transmit process restarts when the flextdm regains synchronization. the auxiliary channel b receiver generates an interrupt after it loads into arb register a new c/i command. a new command is recognized when it is different from the previous loaded command. the channel receiver sets the v bit whenever it loads data into the arb register. the cpu clears the v bit when it reads arb. when the receive flextdm loses synchronization, the auxiliary channel b receiver flushes its shift register and stops its receive process. the receive process restarts when the flextdm regains synchronization. the arb contents are not affected by synchronization lost. notes: the GT-96100A sets the v bit whenever it loads data, even if no new command was received. however, the GT-96100A interrupts the cpu only when new command was received. when the flextdm loses synchronization (i.e., when sync is not asserted where expected), the v bit is cleared, even if new data has been loaded into atb register. this prevents the new data from being transmitted. the driver software must rewrite the data to the atb register when there is loss of synchro- nization (loss of synchronization can be recognized using an interrupt or by polling). 15.10 iom programing table 359 , table 360 and table 361 provide the recommended dpram programming for the iom bus. if iom mode is selected, the programming recommendations must be followed for the appropriate collision resolution process. note: in these tables, b channels mask bits are set to ?1?. however, the cpu must complete layer-2 negotia- tions before granting a mpsc access to one of the b channels. table 359: iom-1 programming entry number l rpt strb b ch mask comments 0 0 00 xx 1 00000 11111111 b channel 0 to mpsc0 (1 byte). 1 0 00 xx 1 00001 11111111 b channel 1 to mpsc1 (1 byte). 2 0 00 xx 1 11110 11111111 monitor to auxa (1 byte). 3 0 01 xx 0 00010 00000110 d channel to mpsc2 (2 bits). note: the mask setting for d channel data. 4 0 11 xx 0 11111 00000010 c/i to auxb (4 bits). GT-96100A advanced communication controller 392 revision 1.0 5 0 00 xx 0 11110 00010001 or 00010011 receive: mx bit to auxa (1bit). transmit: force 0 or 1 on mr using mask[1:0] (1bit). 6 1 00 xx 0 11110 00100001 or 00100011 receive: mr bit to auxa (1bit). transmit: force 0 or 1 on mx using mask[1:0] (1bit). l indicates last entry in frame. table 360: iom2-te programming entry no l rpt strb b ch mask comments 0 0 00 xx 1 00000 11111111 b channel 0 (in iom channel 0) to mpsc0 (1 byte). 1 0 00 xx 1 00001 11111111 b channel 1 (in iom channel 0) to mpsc1 (1 byte). 2 0 00 xx 1 11110 11111111 monitor (in iom channel 0) to auxa (1 byte). 3 0 01 xx 0 00010 00000110 d channel (in iom channel 0) to mpsc2 (2 bits). note the mask setting for d channel data. 4 0 11 xx 0 11111 00000010 c/i (in iom channel 0) to auxb (4 bits). 5 0 00 xx 0 11110 00010001 or 00010011 receive: mx bit (in iom channel 0) to auxa (1bit). transmit: force 0 or 1 on mr using mask[1:0] (1bit). 6 0 00 xx 0 11110 00100001 or 00100011 receive: mr bit (in iom channel 0) to auxa (1bit). transmit: force 0 or 1 on mx using mask[1:0] (1bit). 7 0 11 xx 1 11110 00000000 skip iom channel 1 (4 bytes). 8 0 10 xx 1 11110 00000000 skip part of iom channel 2 (3 bytes). 9 0 01 xx 0 11110 00000000 skip more (2 bits). 10 0 00 xx 0 11110 00001000 d-grant/d-req bit in c/i channel of iom channel 2 (1 bit). table 359: iom-1 programming (continued) entry number l rpt strb b ch mask comments GT-96100A advanced communication controller revision 1.0 393 11 0 11 xx 0 11110 00000000 skip (4 bits). 12 1 00 xx 0 11110 00000000 skip to end of frame (1 bit). l is set to indicate last entry in frame. table 361: iom2-lc (connected to channel 3) gci entry no l rpt strb b ch mask comments 0 0 11 xx 1 11110 00000000 skip iom channel 0 (4 bytes). 1 0 11 xx 1 11110 00000000 skip iom channel 1 (4 bytes). 2 0 11 xx 1 11110 00000000 skip iom channel 2 (4 bytes). 3 0 00 xx 1 00000 11111111 b channel 0 (in iom channel 3) to mpsc0 (1 byte). 4 0 00 xx 1 00001 11111111 b channel 1 (in iom channel 3) to mpsc1 (1 byte). 5 0 00 xx 1 11110 11111111 monitor (in iom channel 3) to auxa (1 byte). 6 0 01 xx 0 00010 00000110 d channel (in iom channel 3) to mpsc2 (2 bits). note: the mask setting for d channel data. 7 0 11 xx 0 11111 00000010 c/i (in iom channel 3) to auxb (4 bits). 8 0 00 xx 0 11110 00010001 or 00010011 receive: mx bit (in iom channel 3) to auxa (1bit). transmit: force 0 or 1 on mr using mask[1:0] (1bit). 9 0 00 xx 0 11110 00100010 or 00100011 receive: mr bit (in iom channel 3) to auxa (1bit). transmit: force 0 or 1 on mx using mask[1:0] (1bit). 10 0 11 xx 1 11110 00000000 skip iom channel 4 (4 bytes). 11 0 11 xx 1 11110 00000000 skip iom channel 5 (4 bytes). table 360: iom2-te programming (continued) entry no l rpt strb b ch mask comments GT-96100A advanced communication controller 394 revision 1.0 15.11 flextdm registers 12 0 11 xx 1 11110 00000000 skip iom channel 6 (4 bytes). 13 1 11 xx 1 11110 00000000 skip iom channel 7 (4 bytes). l is set to indicate last entry in frame. table 362: flextdm register map description offset page number flextdm0 flextdm0 transmit dual port ram (tdpr0), block 0 0x000 b 00 - 0x000 b ff flextdm0 transmit dual port ram (tdpr0), block 1 0x001 b 00 - 0x001 b ff flextdm0 transmit dual port ram (tdpr0), block 2 0x002 b 00 - 0x002 b ff flextdm0 transmit dual port ram (tdpr0), block 3 0x003 b 00 - 0x003 b ff flextdm0 receive dual port ram (rdpr0), block 0 0x004 b 00 - 0x004 b ff flextdm0 receive dual port ram (rdpr0), block 1 0x005 b 00 - 0x005 b ff flextdm0 receive dual port ram (rdpr0), block 2 0x006 b 00 - 0x006 b ff flextdm0 receive dual port ram (rdpr0), block 3 0x007 b 00 - 0x007 b ff flextdm0 transmit read pointer (trp0) 0x008 b 00 flextdm0 receive read pointer (trp0) 0x008 b 04 flextdm0 configuration register (tcr0) 0x008 b 08 page 384 flextdm0 aux channela tx register (ata0) 0x008 b 0c flextdm0 aux channela rx register (ara0) 0x008 b 10 flextdm0 aux channelb tx register (atb0) 0x008 b 14 flextdm0 aux channelb rx register (arb0) 0x008 b 18 flextdm1 flextdm1 transmit dual port ram (tdpr1), block 0 0x010 b 00 - 0x010 b ff flextdm1 transmit dual port ram (tdpr1), block 1 0x011 b 00 - 0x011 b ff flextdm1 transmit dual port ram (tdpr1), block 2 0x012 b 00 - 0x012 b ff flextdm1 (continued) table 361: iom2-lc (connected to channel 3) gci (continued) entry no l rpt strb b ch mask comments GT-96100A advanced communication controller revision 1.0 395 flextdm1 transmit dual port ram (tdpr1), block 3 0x013 b 00 - 0x013 b ff flextdm1 receive dual port ram (rdpr1), block 0 0x014 b 00 - 0x014 b ff flextdm1 receive dual port ram (rdpr1), block 1 0x015 b 00 - 0x015 b ff flextdm1 receive dual port ram (rdpr1), block 2 0x016 b 00 - 0x016 b ff flextdm1 receive dual port ram (rdpr1), block 3 0x017 b 00 - 0x017 b ff flextdm1 transmit read pointer (trp1) 0x018 b 00 flextdm1 receive read pointer (trp1) 0x018 b 04 flextdm1 configuration register (tcr1) 0x018 b 08 page 384 flextdm1 aux channela tx register (ata1) 0x018 b 0c flextdm1 aux channela rx register (ara1) 0x018 b 10 flextdm1 aux channelb tx register (atb1) 0x018 b 14 flextdm1 aux channelb rx register (arb1) 0x018 b 18 flextdm2 flextdm2 transmit dual port ram (tdpr2), block 0 0x020 b 00 - 0x020 b ff flextdm2 transmit dual port ram (tdpr2), block 1 0x021 b 00 - 0x021 b ff flextdm2 transmit dual port ram (tdpr2), block 2 0x022 b 00 - 0x022 b ff flextdm2 transmit dual port ram (tdpr2), block 3 0x023 b 00 - 0x023 b ff flextdm2 receive dual port ram (rdpr2), block 0 0x024 b 00 - 0x024 b ff flextdm2 receive dual port ram (rdpr2), block 1 0x025 b 00 - 0x025 b ff flextdm2 receive dual port ram (rdpr2), block 2 0x026 b 00 - 0x026 b ff flextdm2 receive dual port ram (rdpr2), block 3 0x027 b 00 - 0x027 b ff flextdm2 transmit read pointer (trp2) 0x028 b 00 flextdm2 receive read pointer (trp2) 0x028 b 04 flextdm2 configuration register (tcr2) 0x028 b 08 page 384 flextdm2 aux channela tx register (ata2) 0x028 b 0c flextdm2 aux channela rx register (ara2) 0x028 b 10 flextdm2 aux channelb tx register (atb2) 0x028 b 14 flextdm2 aux channelb rx register (arb2) 0x028 b 18 flextdm3 flextdm3 transmit dual port ram (tdpr3), block 0 0x030 b 00 - 0x030 b ff table 362: flextdm register map (continued) description offset page number GT-96100A advanced communication controller 396 revision 1.0 flextdm3 transmit dual port ram (tdpr3), block 1 0x031 b 00 - 0x031 b ff flextdm3 transmit dual port ram (tdpr3), block 2 0x032 b 00 - 0x032 b ff flextdm3 transmit dual port ram (tdpr3), block 3 0x033 b 00 - 0x033 b ff flextdm3 receive dual port ram (rdpr3), block 0 0x034 b 00 - 0x034 b ff flextdm3 receive dual port ram (rdpr3), block 1 0x035 b 00 - 0x035 b ff flextdm3 receive dual port ram (rdpr3), block 2 0x036 b 00 - 0x036 b ff flextdm3 receive dual port ram (rdpr3), block 3 0x037 b 00 - 0x037 b ff flextdm3 transmit read pointer (trp3) 0x038 b 00 flextdm3 receive read pointer (trp3) 0x038 b 04 flextdm3 configuration register (tcr3) 0x038 b 08 page 384 flextdm3 aux channela tx register (ata3) 0x038 b 0c flextdm3 aux channela rx register (ara3) 0x038 b 10 flextdm3 aux channelb tx register (atb3) 0x038 b 14 flextdm3 aux channelb rx register (arb3) 0x038 b 18 table 362: flextdm register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 397 16. b aud r ate g enerators (brg s ) there are eight baud rate generators (brgs) in the GT-96100A. figure 76 shows a brg block diagram. figure 76: baud rate generator block diagram 16.1 brg inputs and outputs there are 19 clock inputs to the baud rate generators (brgs). two general purpose pins can be programmed to function as clock inputs for the brgs: gpp[0] and gpp[1]. additionally, each of the serial input clocks can be used as a brg clock. finally, the tclk, which is the system parallel clock, is also an option. when a brg is enabled, it loads the count down value (cdv), from the brg configuration register, into its count down counter. when the counter expires (i.e. reaches zero), the brg clock output, bclk, is toggled and the counter reloads. 16.2 brg baud tuning a baud tuning mechanism can be used to adjust the generated clock rate to the receive clock rate. when baud tuning is enabled, the baud tuning mechanism monitors for a start bit, i.e. high-to-low transition. when a start bit is found, the baud tuning machine measures the bit length by counting up until the next low-to- high transition. the count-up value of the brg is then loaded into the count up value (cuv) register and a maskable interrupt is generated signaling the cpu that the bit length value is available. the cpu reads the value from the cuv and adjusts the cdv to the requested value. the cuv can be used to adjust the cdv, in the brg configuration register, to the requested value. tclk sclk[7:0] mux 16bit count down 1/2 zero_count bclk rxd baud tuning load (16 bit count up) count sel_1/1 mux clksel tsclk[7:0] gpp[1:0] GT-96100A advanced communication controller 398 revision 1.0 16.3 brg registers table 363: brg registers map register name offset page brg0 brg0 configuration register (bcr0) 0x102 a 00 page 399 brg0 baud tuning register (btr0) 0x102 a 04 page 400 brg1 brg1 configuration register (bcr1) 0x102 a 08 for a description of the brg1 regis- ters, see the descriptions for the brg0 registers. brg1 baud tuning register (btr1) 0x102 a 0c brg2 brg2 configuration register (bcr2) 0x102 a 10 for a description of the brg2 regis- ters, see the descriptions for the brg0 registers. brg2 baud tuning register (btr2) 0x102 a 14 brg3 brg3 configuration register (bcr3) 0x102 a 18 for a description of the brg3 regis- ters, see the descriptions for the brg0 registers. brg3 baud tuning register (btr3) 0x102 a 1c brg4 brg4 configuration register (bcr4) 0x102 a 20 for a description of the brg4 regis- ters, see the descriptions for the brg0 registers. brg4 baud tuning register (btr4) 0x102 a 24 brg5 brg5 configuration register (bcr5) 0x102 a 28 for a description of the brg5 regis- ters, see the descriptions for the brg0 registers. brg5 baud tuning register (btr5) 0x102 a 2c brg6 brg6 configuration register (bcr6) 0x102 a 30 for a description of the brg6 regis- ters, see the descriptions for the brg0 registers. brg6 baud tuning register (btr6) 0x102 a 34 brg7 brg7 configuration register (bcr7) 0x102 a 38 for a description of the brg7 regis- ters, see the descriptions for the brg0 registers. brg7 baud tuning register (btr7) 0x102 a 3c GT-96100A advanced communication controller revision 1.0 399 table 364: brgx configuration register (bcr) bits name description reset value 15:0 cdv count down value. the user programs the cdv field to define the baud rate that the brg gen- erates. cdv is loaded into the brg counter every time it reaches 0. the actual baud rate is: when cdv is 0x0000, the generated baud rate is equal to the input clock rate. 0 16 en enable brg 0 - disabled. output clock is clamped to 0. 1 - enabled. 0 17 rst reset brg 0 - no op. 1 - reset brg counter to 0. 0 22:18 clks clock source (input clock to the brg) 00000 - bclk0 (from gpp[0] pin) 00001 - bclk1 (from gpp[1] pin) 00010 - sclk0 (from pa[5] pin) 00011 - tsclk0 (from pa[6] pin) 00100 - sclk1 (from pb[5] pin) 00101 - tsclk1 (from pb[6] pin) 00110 - sclk2 (from pc[5] pin) 00111 - tsclk2 (from pc[6] pin) 01000 - sclk3 (from pd[5] pin) 01001 - tsclk3 (from pd[6] pin) 01010 - sclk4 (from pe[5] pin) 01011 - tsclk4 (from pe[6] pin) 01100 - sclk5 (from pf[5] pin) 01101 - tsclk5 (from pf[6] pin) 01110 - sclk6 (from mii0[12] pin) 01111 - tsclk6 (from mii0[1] pin) 10000 - sclk7 (from mii0[13] pin) 10001 - tsclk7 (from mii0[6] pin) 10010 - tclk 10010 24:23 reserved. 0 baudrate inputclockrate cdv+1 () 2 ------------------------------------- - = GT-96100A advanced communication controller 400 revision 1.0 25 bt baud tuning 0 - disabled 1 - enabled setting bt to 1 enables the baud tuning for the duration of one start bit. when the start bit length calculation is done, the GT-96100A clears the bt bit. 0 31:24 reserved 0 table 365: brgx baud tuning register (btr) note: if the brg is written for a clock source that is inactive, this register cannot be accessed, see table 364 bits [22:18]. bits name description reset value 15:0 cuv count up value note: these bits are read only. 0 31:16 reserved. 0 table 364: brgx configuration register (bcr) (continued) bits name description reset value GT-96100A advanced communication controller revision 1.0 401 17. w atchdog t imer the GT-96100A internal watchdog timer is a 32-bit count down counter that can be used to generate a non- maskable interrupt or reset the system in the event of unpredictable software behavior. after the watchdog is enabled, it is a free running counter that needs to be serviced periodically in order to pre- vent its expiration. 17.1 watchdog registers figure 77: watchdog register map table 366: watchdog configuration register (wdc), offset: 0x101a80 bits field name function initial value 23:0 preset_val this field holds the 24 most significant bits which the watchdog counter loads each time it is enabled or serviced. after reset, this field is set to 0xff.ffff. the preset value is equal to {0xpreset_val,ff}. 0xff.ffff 25:24 ctl1 a write sequence of ?01? followed by ?10? into ctl1 disables/enables the watchdog. 00 27:26 ctl2 a write sequence of ?01? followed by ?10? to ctl2 services the watch- dog timer. 00 28 reserved. 0 29 nmi non-maskable interrupt when the watchdog counter reaches a value equal to nmi_val, this bit is asserted. this pin can be used to drive the processor?s nmi* pin. this bit is read only. 1 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 wdc 0x101a80 wdv 0x101a84 wde en nmi preset_val nmi_val ctl1 ctl2 offset register GT-96100A advanced communication controller 402 revision 1.0 17.2 watchdog operation after reset, the watchdog is disabled. the watchdog must be serviced periodically in order to avoid nmi or reset (wde*). watchdog service is per- formed by writing ?01? to ctl2, followed by writing ?10? to ctl2. upon watchdog service, the GT-96100A clears the nmi and wde bits (if set) and reloads the preset_val into the watchdog counter. a write sequence of ?01? followed by ?10? into ctl1 disables/enables the watchdog. the watchdog?s current sta- tus can be read in bit 31 of wdc. when disabled, the GT-96100A sets the nmi and wde bits (if clear) and reloads the preset_val into the watchdog counter. preset_val and nmi_val can be changed while the watchdog is enabled. however, preset_val will affect the watchdog only after it is loaded into the watchdog counter (e.g. after watchdog service). if the watchdog is not serviced before the counter reaches nmi_val, a non-maskable interrupt event occurs. a watchdog expiration event occurs. the nmi bit is reset, asserting low the nmi* pin. in order to deassert the nmi* and/or wde* pins, the watchdog must be serviced, disabled or the GT-96100A must be reset. the GT-96100A holds wde* asserted for the duration of 16 system cycles after reset assertion. 30 wde watchdog expiration when the watchdog counter expires, this bit is asserted. the wde* pin can be used to reset the entire system. this bit is read only. 1 31 en enable 0 - watchdog is disabled, counter is loaded with preset_val. nmi and wde are set to ?1?. 1 - watchdog is enabled. this bit is read only. 0 table 367: watchdog value register (wdv), offset: 0x101a84 bits field name function reset value 23:0 nmi_val nmi_val are the 24 least significant bits of a 32-bit value. the upper 8 bits are always ?00?. when the watchdog counter reaches a value equal to the nmi value nmi* pin is asserted. the actual nmi value is a 32-bit number equal to {0x00,nmi_val}. 0x000.0000 31:24 reserved. 0 table 366: watchdog configuration register (wdc), offset: 0x101a80 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 403 18. t imers /c ounters there are three 24-bit wide and one 32-bit wide timer/counters on the GT-96100A. each one can be selected to operate as a timer or as a counter. note: the count frequency for the timer/counters is equal to tclk frequency in counter mode, the counter counts down to terminal count, stops, and issue an interrupt. in timer mode, the timer counts down, issues an interrupt on terminal count, and resets itself to the programmed countdown value, and begins to count down. reads from the counter or timer are done from the counter itself, while writes are to its register. for example, note that even though the registers are programmed to an initial value of 0 the counters read 0xffffff. in order to reprogram a timer/counter: 1. disable the timer/counter. 2. load it with a new value. 3. enable it as appropriate, counter or timer. note: there are no external input pins for enable/disable nor are there any output timer pins on the gt- 96100a. 18.1 timer / counter registers table 368: timer/counter 0, offset: 0x850 bits field name function initial value 31:0 tc0value the counter or timer initial value. 0xffffffff table 369: timer/counter 1, offset: 0x854 bits field name function initial value 23:0 tc1value the counter or timer initial value. 0xffffff 31:24 reserved reserved. 0x0 table 370: timer/counter 2, offset: 0x858 bits field name function initial value 23:0 tc2value the counter or timer initial value. 0xffffff 31:24 reserved reserved. 0x0 GT-96100A advanced communication controller 404 revision 1.0 table 371: timer/counter 3, offset: 0x85c bits field name function initial value 23:0 tc3value the counter or timer initial value. 0xffffff 31:24 reserved reserved. 0x0 table 372: timer/counter control, offset: 0x864 bits field name function initial value 0 entc0 the timer/counter counts only when it is enabled. 0 - disable 1 - enable 0x0 1 seltc0 timer or counter selection 0 - counter 1 - timer 0x0 2 entc1 the timer/counter counts only when it is enabled. 0 - disable 1 - enable 0x0 3 seltc1 timer or counter selection 0 - counter 1 - timer 0x0 4 entc2 the timer/counter counts only when it is enabled. 0 - disable 1 - enable 0x0 5 seltc2 timer or counter selection 0 - counter 1 - timer 0x0 6 entc3 the timer/counter counts only when it is enabled. 0 - disable 1 - enable 0x0 7 seltc3 timer or counter selection 0 - counter 1 - timer 0x0 31:8 reserved reserved. 0x0 GT-96100A advanced communication controller revision 1.0 405 19. g eneral p urpose p orts 19.1 overview the GT-96100A supports up to 88 general purpose pins. most of these pins are shared (multiplexed) with the serial ports (ports a through f) and with the mii ports (mii0 and mii1). the result is that in most applications less than 88 pins can be configured as gpps. however, the con- trol of the ports in GT-96100A is made very flexible, providing the user with a pin level configuration capability. thus, for example, if port a is used for serial communication but one of its pins is not needed (e.g. pa[6]), this single pin can be programmed to function as a general purpose pin, without affecting the other pins associated with the serial function. GT-96100A also provides the capability of generating interrupts for each of the gpp pins. 19.2 general purpose control registers the general purpose registers control the behavior of the pins associated with the gpp function. there are 12 registers, which are divided into 3 groups. the groups are defined as follows: ? group 0 includes gpp, a and b ports. ? group 1 includes c, d, e and f ports. ? group 2 includes mii0 and mii1 ports. each group of registers comprises four registers, used to configure the group pins. table 373: control registers register description general purpose con- figuration registers gpc0, gpc1, and gpc2 these registers control the setting of the pins as either general-purpose i/o or peripheral function. when a pin is configured as peripheral, it?s exact functionality is set according to the port?s connection setting. for example, if port c is connected to mpsc2, pc[0] is used as rxd2. if port c is tied to tdm0, pc[0] can be set to either trxd0 or ttxd0. general purpose input/ output registers gpio0, gpio1, and gpio2 these registers control the direction of the pins (either input or output). note: gpio registers affect pin functionality not only when the pin is configured as general purpose i/o, but also when the pin is configured as peripheral function. for example, if port c is tied to tdm0, setting pc[0] as trxd0 (input) or ttxd0 (output) is done by programming gpio1 accordingly. GT-96100A advanced communication controller 406 revision 1.0 the registers are described in the following tables. general purpose data registers gpd0, gpd1, and gpd2 these registers hold the data associated with the general purpose i/o pins. these registers? bits are read-only for general purpose inputs and are read-write for gen- eral purpose outputs. the data read from these registers reflect the pin state, while writing to these registers sets the data to be driven out (for output pins). when a gpp pin is configured as input and its associated gpd bit is 0, an interrupt is set. an interrupt is set regardless of the gpc state. general purpose level registers gpl0, gpl1, and gpl2 these registers define the polarity associated with pins that are configured as gen- eral purpose input. for each pin defined as asserted low, the pin state is inverted before being processed in the device. thus, if a pin is externally tied to ?0?, but is configured in the gpl register as negative polarity, the data read from the respec- tive gpd bit is ?1?. table 374: gpp registers map description offset page number general purpose configuration general purpose configuration 0 (gpc0) 0x100 a 00 page 407 general purpose configuration 1 (gpc1) 0x100 a 04 page 409 general purpose configuration 2 (gpc2) 0x100 a 08 page 412 general purpose input/output general purpose input/output 0 (gpio0) 0x100 a 20 page 407 general purpose input/output 1 (gpio1) 0x100 a 24 page 410 general purpose input/output 2 (gpio2) 0x100 a 28 page 412 general purpose data general purpose data 0 (gpd0) 0x100 a 40 page 408 general purpose data 1 (gpd1) 0x100 a 44 page 410 general purpose data 2 (gpd2) 0x100 a 48 page 413 general purpose level general purpose level 0 (gpl0) 0x100 a 60 page 408 general purpose level 1 (gpl1) 0x100 a 64 page 411 general purpose level 2 (gpl2) 0x100 a 68 page 413 table 373: control registers (continued) register description GT-96100A advanced communication controller revision 1.0 407 table 375: general purpose configuration 0 (gpc0), offset: 0x100a00 bits field name function initial value 15:0 gppc general purpose port configuration each bit controls the setting of the respective pin in the gpp port. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 22:16 pac port a configuration each bit controls the setting of the respective pin in port a. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 23 reserved. 0 30:24 pbc port b configuration each bit controls the setting of the respective pin in port b. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 31 reserved. 0 table 376: general purpose input/output 0 (gpio0), offset: 0x100a20 bits field name function initial value 15:0 gppio general purpose port i/o each bit controls the setting of the respective pin in the gpp port as input or output. 0 - pin is configured as input. 1 - pin is configured as output. 0 22:16 paio port a i/o each bit controls the setting of the respective pin in port a as input or output. 0 - pin is configured as input. 1 - pin is configured as output. 0 23 reserved. 0 30:24 pbio port b i/o. each bit controls the setting of the respective pin in port b as input or output. 0 - pin is configured as input. 1 - pin is configured as output. 0 31 reserved. 0 GT-96100A advanced communication controller 408 revision 1.0 table 377: general purpose data 0 (gpd0), offset: 0x100a40 bits field name function initial value 15:0 gppd general purpose port data each bit holds the data of the respective pin in gpp port. if the pin is config- ured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 22:16 pad port a data each bit holds the data of the respective pin in port a. if the pin is configured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 23 reserved. 0 30:24 pbd port b data each bit holds the data of the respective pin in port b. if the pin is configured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 31 reserved. 0 table 378: general purpose level 0 (gpl0), offset: 0x100a60 bits field name function initial value 15:0 gppl general purpose port level each bit defines the polarity of the respective pin in gpp port. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 22:16 pal port a level each bit defines the polarity of the respective pin in port a. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 23 reserved. 0 30:24 pbl port b level each bit defines the polarity of the respective pin in port b. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 GT-96100A advanced communication controller revision 1.0 409 31 reserved. 0 table 379: general purpose configuration 1 (gpc1), offset: 0x100a04 bits field name function initial value 6:0 pcc port c configuration each bit controls the setting of the respective pin in port c. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 7 reserved. 0 14:8 pdc port d configuration each bit controls the setting of the respective pin in port d. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 15 reserved. 0 22:16 pec port e configuration each bit controls the setting of the respective pin in port e. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 23 reserved. 0 30:24 pfc port f configuration each bit controls the setting of the respective pin in port f. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 31 reserved. 0 table 378: general purpose level 0 (gpl0), offset: 0x100a60 (continued) bits field name function initial value GT-96100A advanced communication controller 410 revision 1.0 table 380: general purpose input/output 1 (gpio1), offset: 0x100a24 bits field name function initial value 6:0 pcio port c i/o each bit controls the setting of the respective pin in port c as input or output. 0 - pin is configured as input. 1 - pin is configured as output. 0 7 reserved. 0 14:8 pdio port d i/o each bit controls the setting of the respective pin in port d as input or output. 0 - pin is configured as input. 1 - pin is configured as output. 0 15 reserved. 0 22:16 peio port e i/o each bit controls the setting of the respective pin in port e as input or output. 0 - pin is configured as input. 1 - pin is configured as output. 0 23 reserved. 0 30:24 pfio port f i/o each bit controls the setting of the respective pin in port f as input or output. 0 - pin is configured as input. 1 - pin is configured as output. 0 31 reserved. 0 table 381: general purpose data 1 (gpd1), offset: 0x100a44 bits field name function initial value 6:0 pcd port c data each bit holds the data of the respective pin in port c. if the pin is configured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 7 reserved 0 14:8 pdd port d data each bit holds the data of the respective pin in port d. if the pin is configured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 GT-96100A advanced communication controller revision 1.0 411 15 reserved 0 22:16 ped port e data each bit holds the data of the respective pin in port e. if the pin is configured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 23 reserved 0 30:24 pfd port f data each bit holds the data of the respective pin in port f. if the pin is configured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 31 reserved 0 table 382: general purpose level 1 (gpl1), offset: 0x100a64 bits field name function initial value 6:0 pcl port c level each bit defines the polarity of the respective pin in port c. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 7 reserved. 0 14:8 pdl port d level each bit defines the polarity of the respective pin in port d. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 15 reserved. 0 22:16 pel port e level each bit defines the polarity of the respective pin in port e. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 23 reserved. 0 table 381: general purpose data 1 (gpd1), offset: 0x100a44 (continued) bits field name function initial value GT-96100A advanced communication controller 412 revision 1.0 30:24 pfl port f level each bit defines the polarity of the respective pin in port f. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 31 reserved. 0 table 383: general purpose configuration 2 (gpc2), offset: 0x100a08 bits field name function initial value 14:0 mii0c port mii0 configuration each bit controls the setting of the respective pin in port mii0. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 15 reserved. 0 30:16 mii1c port mii1 configuration each bit controls the setting of the respective pin in port mii1. 0 - pin is configured as general purpose i/o. 1 - pin is configured as peripheral function. 0 31 reserved. 0 table 384: general purpose input/output 2 (gpio2), offset: 0x100a28 bits field name function initial value 14:0 mii0io port mii0 i/o each bit controls the setting of the respective pin in port mii0 as input or out- put. 0 - pin is configured as input. 1 - pin is configured as output. 0 15 reserved. 0 30:16 mii1io port mii1 i/o each bit controls the setting of the respective pin in port mii1 as input or out- put. 0 - pin is configured as input. 1 - pin is configured as output. 0 table 382: general purpose level 1 (gpl1), offset: 0x100a64 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 413 31 reserved. 0 table 385: general purpose data 2 (gpd2), offset: 0x100a48 bits field name function initial value 14:0 mii0d port mii0 data each bit holds the data of the respective pin in port mii0. if the pin is config- ured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 15 reserved. 0 30:16 mii1d port mii1 data each bit holds the data of the respective pin in port mii1. if the pin is config- ured as input, this bit is read-only and reflects the signal status at the pin. if the pin is configured as output, this bit is read-write and controls the data driven out. 0 31 reserved. 0 table 386: general purpose level 2 (gpl2), offset: 0x100a68 bits field name function initial value 14:0 mii0l port mii0 level. each bit defines the polarity of the respective pin in port mii0. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 15 reserved. 0 30:16 mii1l port mii1 level each bit defines the polarity of the respective pin in port mii1. 0 - positive (normal) polarity. 1 - negative polarity. if the pin is configured as input, it is inverted before being processed inside the device. 0 31 reserved. 0 table 384: general purpose input/output 2 (gpio2), offset: 0x100a28 (continued) bits field name function initial value GT-96100A advanced communication controller 414 revision 1.0 20. p hysical s ignal r outing 20.1 signal routing there are six serial ports on the GT-96100A?s ports a?f and the mii0 port which are used to externally route the mpscs, flextdms, and the general purpose interface signals. the actual physical routing of the mpsc and tdm signals are defined in the main routing register (mrr), see table 387 . table 387: mpsc routing register (mrr), offset: 0x101a00 bits field name function initial value 2:0 mr0 mpsc0 routing 000 - port a 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc0, port a is connected to the pci arbiter or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. 111 5:3 mr1 mpsc1 routing 000 - port b 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc1, port b is connected to the pci arbiter or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. 111 GT-96100A advanced communication controller revision 1.0 415 8:6 mr2 mpsc2 routing 000 - port c 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc2, port c is connected to tdm0 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. 111 11:9 mr3 mpsc3 routing 000 - port d 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc3, port d is connected to tdm1 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. 111 14:12 mr4 mpsc4 routing 000 - port e 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc4, port e is connected to tdm2 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. 111 table 387: mpsc routing register (mrr), offset: 0x101a00 (continued) bits field name function initial value GT-96100A advanced communication controller 416 revision 1.0 17:15 mr5 mpsc5 routing 000 - port f 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc5, port f is connected to tdm3 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. 111 20:18 mr6 mpsc6 routing 000 - port mii0 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc6, port mii0 is connected to ethernet 0 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. note: proper operation of mii interface for ethernet 0 requires that fields mr6 and mr7 cannot be set to value ?000?. any other value is a valid setting. the rmii interface can be used for employing both mpsc6 and ethernet 0. see table 289 for more details. 111 table 387: mpsc routing register (mrr), offset: 0x101a00 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 417 note: when a mpsc is connected to a flextdm, it?s clocks come from the flextdm unit regardless of the content of crr/crt. 23:21 mr7 mpsc7 routing 000 - port mii0 001 - flextdm0 010 - flextdm1 011 - flextdm2 100 - flextdm3 101 - reserved 110 - reserved 111 - unconnected (default) when not connected to mpsc7, port mii0 is connected to ethernet 0 or used as gpp. see section 19. ?general purpose ports? on page 405 for more details. note: proper operation of mii interface for ethernet 0 requires that fields mr6 and mr7 cannot be set to value ?000?. any other value is a valid setting. the rmii interface can be used for employing both mpsc7 and ethernet 0. see table 289 for more details. 111 31:24 reserved. 0 table 387: mpsc routing register (mrr), offset: 0x101a00 (continued) bits field name function initial value GT-96100A advanced communication controller 418 revision 1.0 20.2 clock routing the mpscs? receive and transmit clocks use the baud rate generators or serial clock input signals. the routing of these signals is defined in the rx clock routing register (rcrr) and the tx clock routing register (tcrr). table 388: rx clock routing register (rcrr), offset: 0x101a10 bits field name function initial value 3:0 crr0 mpsc0 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk0 1001 to 1111 - reserved 0000 7:4 crr1 mpsc1 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk1 1001 to 1111 - reserved 0000 11:8 crr2 mpsc2 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk2 1001 to 1111 - reserved 0000 GT-96100A advanced communication controller revision 1.0 419 15:12 crr3 mpsc3 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk3 1001 to 1111 - reserved 0000 19:16 crr4 mpsc4 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk4 1001 to 1111 - reserved 0000 23:20 crr5 mpsc5 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk5 1001 to 1111 - reserved 0000 table 388: rx clock routing register (rcrr), offset: 0x101a10 (continued) bits field name function initial value GT-96100A advanced communication controller 420 revision 1.0 27:24 crr6 mpsc6 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk6 1001 to 1111 - reserved 0000 31:28 crr7 mpsc7 rx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk7 1001 to 1111 - reserved 0000 table 389: tx clock routing register (tcrr), offset: 0x101a20 bits field name function initial value 3:0 crt0 mpsc0 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk0 1001 - tsclk0 1010 to 1111 - reserved 0000 table 388: rx clock routing register (rcrr), offset: 0x101a10 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 421 7:4 crt1 mpsc1 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk1 1001 - tsclk1 1010 to 1111 - reserved 0000 11:8 crt2 mpsc2 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk2 1001 - tsclk2 1010 to 1111 - reserved 0000 15:12 crt3 mpsc3 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk3 1001 - tsclk3 1010 to 1111 - reserved 0000 table 389: tx clock routing register (tcrr), offset: 0x101a20 (continued) bits field name function initial value GT-96100A advanced communication controller 422 revision 1.0 19:16 crt4 mpsc4 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk4 1001 - tsclk4 1010 to 1111 - reserved 0000 23:20 crt5 mpsc5 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk5 1001 - tsclk5 1010 to 1111 - reserved 0000 27:24 crt6 mpsc6 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk6 1001 - tsclk6 1010 to 1111 - reserved 0000 table 389: tx clock routing register (tcrr), offset: 0x101a20 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 423 31:28 crt7 mpsc7 tx clock routing 0000 - brg0 0001 - brg1 0010 - brg2 0011 - brg3 0100 - brg4 0101 - brg5 0110 - brg6 0111 - brg7 1000 - sclk7 1001 - tsclk7 1010 to 1111 - reserved 0000 table 389: tx clock routing register (tcrr), offset: 0x101a20 (continued) bits field name function initial value GT-96100A advanced communication controller 424 revision 1.0 21. i nterrupt c ontroller the GT-96100A provides four interrupt pins that can be used for generating interrupts to the cpu: ? interrupt0* ? interrupt1* ? serint0* ? serint1* the GT-96100A also integrates a programmable interrupt controller that is capable of routing each of the internal interrupt requests to one (or more) of the interrupt pins. the interrupt controller performs a logical or of all internal interrupt events and asserts an interrupt to the cpu when at least one of the (unmasked) events is set. the interrupt pins provided by the GT-96100A can be used in any system which supports multiple interrupt sig- nals. if the cpu is capable of handling multiple interrupt inputs, connect the GT-96100A pins directly to the cpu. if the system requires a pci directed interrupt, connect one of the pins to the pci and the remaining pins to the cpu. the two serial interrupt pins (serint0*, serint1*) allow separation of communication interrupts from other sys- tem events. only events that originate within the communication unit can be routed to the serial interrupt pins. 21.1 interrupt cause registers there are two high-level interrupt cause registers, which serve to indicate the occurrence of certain events. one cause register (main_cause register) consists of events originating in the GT-96100A?s system controller logic. this register is located at offset 0x000c18. the other cause register (high_cause register) consists of events originating in the pci_1 unit and the communi- cation unit. this register is located at offset 0x000c1c. note: there is another cause register dedicated to communication events. this register (serial_cause register) is located at 0x103a00. when an interrupt event occurs, a bit in one of the cause registers is set. all bits in the cause register(s) are ored together, and the result is driven on one of the interrupt* lines. the interrupt* causes the cpu to read the inter- rupt cause registers and run a service routine depending on the interrupt being serviced. the interrupt is acknowledged by the cpu resetting bits in the cause register. the specific bit that is reset depends on the interrupt event being serviced. reset a bit by writing ?0? to this bit and ?1? to all other bits. note: an exception to the above is the cpuint ([25:22]) and pciint ([29:26]) bits, which are intended for gen- erating pcitocpu and cputopci interrupts. set these bits by writing ?0? from the interrupt originating side. clear these bits by writing ?0? from the interrupt destination side. for example, if one of the pci agents needs to assert an interrupt to the cpu, it can write ?0? to one of the pciint bits in the main_cause register. assuming that this bit is not masked, interrupt0* will be asserted. after servicing this interrupt the cpu should clear the interrupt bit by writing zero to it. GT-96100A advanced communication controller revision 1.0 425 21.1.1 communication unit cause registers the GT-96100A includes 16 second level cause registers used to trap events generated within the communication unit. each interrupt source in the communication unit is tied to one of these second level cause registers. each of these registers is tied to specific bits in the high_cause register and in the serial_cause register. these bits function as summary bits, and are set when specific bits in the cause register are asserted (i.e. each summary bit is equivalent to a logical or of some bits in one of the cause registers). these summary bits are read-only. when an interrupt event occurs in the communication unit, a bit is set in one of the second level cause registers. this bit, if not masked, asserts one of the summary bits in the high_cause register and in the serial_cause regis- ter. following that, one (or more) of the interrupt lines is asserted. the cpu recognizes an interrupt that is due to the communication unit when one of the summary bits in the high_cause register is set or when one of the summary bits in the serial_cause register is set. based on the spe- cific bit set, the cpu reads the second level cause register associated with this bit in order to identify the actual interrupt event that generated the interrupt. in order to acknowledge the interrupt, the cpu must write zero to this bit in the cause register. note: the cpu cannot reset the summary bits directly, because these bits are read-only. a summary bit is automatically reset when the cpu resets the bits in the related second level cause register. 21.2 interrupt mask registers the GT-96100A provides interrupt mask registers for each of the internal cause registers. these mask registers allow masking of certain events, so that only specific events (as selected by the user) actually cause assertion of one of the interrupts. there are two mask registers associated with interrupt0* and two mask registers associated with interrupt1*. these mask registers are used for enabling events that cause the assertion of either of these interrupts. for interrupt0*, these mask registers are located at 0x000c1c and at 0x000c9c. for interrupt1*, the mask registers are located at 0x000c24 and at 0x000c38. programming ?0? in a mask register bit disables the associated event from asserting interrupt. programming ?1? allows the interrupt event to cause interrupt signal assertion. in addition, there is one mask register associated with each of the serial interrupt pins. for serint0* the mask reg- ister is located at 0x103a80 and for serint1* the mask register is located at 0x103a88. GT-96100A advanced communication controller 426 revision 1.0 21.3 interrupt summaries the GT-96100A provides the following three interrupt summary bits in the main cause register: ? intsum (bit [0] in the main_cause register) is the logical or of all interrupt bits in both the main_cause and high_cause registers. this or is not affected by the state of the mask bits and can be used for event polling. ? int0*sum (bit [30] in the main_cause register) is the logical or of all interrupt bits in both the main_cause and high_cause registers masked by interrupt0* mask registers. it serves as an indication that at least one of the (unmasked) interrupt0* events is set. ? int1*sum (bit [31] in the main_cause register) is the logical or of all interrupt bits in both the main_cause and high_cause registers masked by interrupt1* mask registers. it serves as an indication that at least one of the (unmasked) interrupt1* events is set. 21.4 interrupt select registers there are two interrupt select registers that can be used to optimize interrupt service routines. one select register is associated with interrupt0* (offset 0x000c70) and another register is associated with interrupt1* (offset 0x000c74). these select registers optimize service routines is the following manner: ? instead of checking both the main_cause register and the high_cause register, when interrupted, the cpu has the option to read the appropriate select register. ? the select register will reflect the cause register bits of either the main_cause or the high_cause regis- ters, depending on which register has active unmasked interrupt bits. ? bit [30] of the select register indicates which of the cause registers (main or high) is selected and bits [29:0] reflect the state of the interrupt bits of the selected cause register. for example, if bit [5] of the high_cause register is set (and is unmasked), and no (unmasked) bit in the main_cause register is set, then bit [5] of the select register is set as well. in addition, bit [30] of the select register is set, indicating that the high_cause register is currently being selected. in case both the main_cause and the high_cause registers have interrupt bits set, the select register reflects the state of the main_cause register (and bit [30] is therefore reset). however, in order to indicate that both cause registers are active, bit [31] of the select register is also set, in this case. GT-96100A advanced communication controller revision 1.0 427 21.5 interrupt registers tables table 390: interrupt registers map register name offset page number interrupt main cause register 0x000c18 page 428 interrupt0* main mask register 0x000c1c page 432 interrupt1* main mask register 0x000c24 page 434 interrupt high cause register 0x000c98 page 430 interrupt0* high mask register 0x000c9c page 433 interrupt1* high mask register 0x000ca4 page 435 interrupt0* select register 0x000c70 page 431 interrupt1* select register 0x000c74 page 432 serial cause register 0x103a00 page 436 serint0* mask register 0x103a80 page 438 serint1* mask register 0x103a88 page 439 ethernet0 cause register 0x084850 page 440 ethernet0 mask register 0x084858 page 440 ethernet1 cause register 0x088850 page 441 ethernet1 mask register 0x088858 page 441 sdma cause register 0x103a10 page 441 sdma mask register 0x103a90 page 441 mpsc0 cause register 0x103a20 page 444 mpsc0 mask register 0x103aa0 page 444 mpsc1 cause register 0x103a24 page 445 mpsc1 mask register 0x103aa4 page 445 mpsc2 cause register 0x103a28 page 445 mpsc2 mask register 0x103aa8 page 445 mpsc3 cause register 0x103a2c page 446 mpsc3 mask register 0x103aac page 446 mpsc4 cause register 0x103a30 page 446 mpsc4 mask register 0x103ab0 page 446 mpsc5 cause register 0x103a34 page 446 mpsc5 mask register 0x103ab4 page 446 GT-96100A advanced communication controller 428 revision 1.0 mpsc6 cause register 0x103a38 page 446 mpsc6 mask register 0x103ab8 page 446 mpsc7 cause register 0x103a3c page 446 mpsc7 mask register 0x103abc page 446 flextdm cause register 0x103a40 page 447 flextdm mask register 0x103ac0 page 447 brg cause register 0x103a48 page 448 brg mask register 0x103ac8 page 448 gpp0 cause register 0x103a50 page 448 gpp0 mask register 0x103ad0 page 448 gpp1 cause register 0x103a54 page 449 gpp1 mask register 0x103ad4 page 449 gpp2 cause register 0x103a58 page 449 gpp2 mask register 0x103ad8 table 391: in terrupt main cause register, offset: 0x000c18 bits field name function initial value 0 intsum interrupt summary logical or of all the interrupt bits, regardless of the mask registers? values. this bit is read-only. 0 1 memout asserts when the cpu or pci accesses an address out of range in the memory decoding or a burst access to 8- 16-bit devices. 0 2 dmaout asserts when the dma or communication unit accesses an address out of range. 0 3 cpuout asserts when the cpu accesses an address out of range. 0 4 dma0comp asserts at completion of dma channel 0 transfer. 0 5 dma1comp asserts at completion of dma channel 1 transfer. 0 6 dma2comp asserts at completion of dma channel 2 transfer. 0 7 dma3comp asserts at completion of dma channel 3 transfer. 0 8 t0exp asserts when timer 0 expires. 0 table 390: interrupt registers map (continued) register name offset page number GT-96100A advanced communication controller revision 1.0 429 9 t1exp asserts when timer 1 expires. 0 10 t2exp asserts when timer 2 expires. 0 11 t3exp asserts when timer 3 expires. 0 12 masrderr0 asserts when the GT-96100A detects a parity error during a pci_0 master read operation. 0 13 slvwrerr0 asserts when the GT-96100A detects a parity error during a pci_0 slave write operation. 0 14 maswrerr0 asserts when the GT-96100A detects a parity error during a pci_0 master write operation. 0 15 slvrderr0 asserts when the GT-96100A detects a parity error during a pci_0 slave read operation. 0 16 addrerr0 asserts when the GT-96100A detects a parity error on the pci_0 address lines. 0 17 memerr asserts when a memory parity error is detected. 0 18 masabort0 asserts upon pci_0 master abort. 0 19 tarabort0 asserts upon pci_0 target abort. 0 20 retryctr0 asserts when the pci_0 retry counter expires. 0 21 pmcint0 if power management is enabled this bit functions as pmc0 interrupt, otherwise it functions as one of the cpuint bits. ? pmcint: asserts when power state bits in pmcsr0 register are updated from pci. ? cpuint: set by the cpu by writing ?0? to generate an inter- rupt on the pci bus. cleared when the pci writes ?0?. 0 25:22 cpuint these bits are set by the cpu by writing ?0? to generate an interrupt on the pci bus. they are cleared when the pci writes ?0?. this requires that interrupt1* is used as a pci interrupt signal. 0 29:26 pciint these bits are set by the pci by writing ?0? to generate an interrupt on the cpu. they are cleared when the cpu writes ?0?. 0 30 int0*sum interrupt summary logical or of all interrupt bits in the main and high cause registers masked by interrupt0* mask registers. this bit is read-only. 0 31 int1*sum interrupt summary logical or of all interrupt bits in the main and high cause registers masked by interrupt1* mask registers. this bit is read-only. 0 table 391: in terrupt main cause register, offset: 0x000c18 (continued) bits field name function initial value GT-96100A advanced communication controller 430 revision 1.0 table 392: interrupt high cause register, offset: 0x000c98 bits field name function initia l value 0 ether0sum ethernet port 0 interrupt summary logical or of all unmasked interrupt bits in the ethernet0_cause reg- ister. this bit is read-only. 0 1 ether1sum ethernet port 1interrupt summary logical or of all unmasked interrupt bits in the ethernet1_cause reg- ister. this bit is read-only. 0 3:2 reserved. 0 4 sdmasum sdma interrupt summary logical or of all unmasked interrupt bits in the sdma_cause register. this bit is read-only. 0 5 mpscsum mpsc interrupt summary logical or of all unmasked interrupt bits in all the mpsc_cause reg- isters. this bit is read-only. 0 6 ftdmsum flextdm interrupt summary logical or of all unmasked interrupt bits in the ftdm_cause register. this bit is read-only. 0 7 brgsum baud rate generators interrupt summary logical or of all unmasked interrupt bits in the brg_cause register. this bit is read-only. 0 8 gpp0sum gpp0 interrupt summary logical or of all unmasked interrupt bits in the gpp0_cause register. this bit is read-only. 0 9 gpp1sum gpp1 interrupt summary logical or of all unmasked interrupt bits in the gpp1_cause register. this bit is read-only. 0 10 gpp2sum gpp2 interrupt summary logical or of all unmasked interrupt bits in the gpp2_cause register. this bit is read-only. 0 11 reserved. 0 12 masrderr1 asserts when the GT-96100A detects a parity error during a pci_1 master read operation. 0 13 slvwrerr1 asserts when the GT-96100A detects a parity error during a pci_1 slave write operation. 0 GT-96100A advanced communication controller revision 1.0 431 14 maswrerr1 asserts when the GT-96100A detects a parity error during a pci_1 master write operation. 0 15 slvrderr1 asserts when the GT-96100A detects a parity error during a pci_1 slave read operation. 0 16 addrerr1 asserts when the GT-96100A detects a parity error on the pci_1 address lines. 0 17 reserved. 0 18 masabort1 asserts upon pci_1 master abort. 0 19 tarabort1 asserts upon pci_1 target abort. 0 20 retryctr1 asserts when the pci_1 retry counter expires. 0 21 pmcint1 if power management is enabled, this bit functions as pmc1 interrupt, otherwise it is reserved. pmc1 asserts when power state bits in pmcsr1 register are updated from pci. 0 23:22 reserved. 0 24 pciarb0 pci_0 arbiter interrupt this bit is set when a ?broken master? condition is detected by pci_0 arbiter. 0 25 pciarb1 pci_1 arbiter interrupt this bit is set when a ?broken master? condition is detected by pci_1 arbiter. 0 31:26 reserved. 0 table 393: interrupt0* select register, offset: 0x000c70 bits field name function initia l value 29:0 aliasedbits aliased to bits [29:0] of the selected cause register. 0 30 selectcause selected cause register 0 - main cause register 1 - high cause register 0 31 lowandhigh interrupt is set in both main and high cause registers. 0 table 392: interrupt high cause register, offset: 0x000c98 (continued) bits field name function initia l value GT-96100A advanced communication controller 432 revision 1.0 table 394: interrupt1* select register, offset: 0x000c74 bits field name function initial value 31:0 various same as for interrupt0* select register. 0 table 395: interrupt0* main mask register, offset: 0x000c1c bits field name function initial value 0 reserved. 0 1 memoutmask masks memout interrupt to interrupt0* 0 2 dmaoutmask masks dmaout interrupt to interrupt0* 0 3 cpuoutmask masks cpuout interrupt to interrupt0* 0 4 dma0compmask masks dma0comp interrupt to interrupt0* 0 5 dma1compmask masks dma1comp interrupt to interrupt0* 0 6 dma2compmask masks dma2comp interrupt to interrupt0* 0 7 dma3compmask masks dma3comp interrupt to interrupt0* 0 8 t0expmask masks t0exp interrupt to interrupt0* 0 9 t1expmask masks t1exp interrupt to interrupt0* 0 10 t2expmask masks t2exp interrupt to interrupt0* 0 11 t3expmask masks t3exp interrupt to interrupt0* 0 12 masrderr0mask masks masrderr0 interrupt to interrupt0* 0 13 slvwrerr0mask masks slvwrerr0 interrupt to interrupt0* 0 14 maswrerr0mask masks maswrerr0 interrupt to interrupt0* 0 15 slvrderr0mask masks slvrderr0 interrupt to interrupt0* 0 16 addrerr0mask masks addrerr0 interrupt to interrupt0* 0 17 memerrmask masks memerr interrupt to interrupt0* 0 18 masabort0mask masks masabort0 interrupt to interrupt0* 0 19 tarabort0mask masks tarabort0 interrupt to interrupt0* 0 20 retryctr0mask masks retryctr0 interrupt to interrupt0* 0 21 pmc0mask if power management is enabled, masks pmc0 interrupt to interrupt0*, otherwise it is reserved (read only 0). 0 25:22 reserved. 0 29:26 pciintmask masks pciint interrupt to interrupt0* 0 GT-96100A advanced communication controller revision 1.0 433 31:30 reserved. 0 table 396: interrupt0* high mask register, offset: 0x000c9c bits field name function initial value 0 ether0summask masks ether0sum to interrupt0* 0 1 ether1summask masks ether1sum to interrupt0* 0 3:2 reserved. 0 4 sdmasummask masks sdmasum to interrupt0* 0 5 mpscsummask masks mpscsum to interrupt0* 0 6 ftdmsummask masks ftdmsum to interrupt0* 0 7 brgsummask masks brgsum to interrupt0* 0 8 gpp0summask masks gpp0sum to interrupt0* 0 9 gpp1summask masks gpp1sum to interrupt0* 0 10 gpp2summask masks gpp2sum to interrupt0* 0 11 reserved. 0 12 masrderr1mask masks masrderr1 to interrupt0* 0 13 slvwrerr1mask masks slvwrerr1 to interrupt0* 0 14 maswrerr1mask masks maswrerr1 to interrupt0* 0 15 slvrderr1mask masks slvrderr1 to interrupt0* 0 16 addrerr1mask masks addrerr1 to interrupt0* 0 17 reserved. 0 18 masabort1mask masks masabort1 to interrupt0* 0 19 tarabort1mask masks tarabort1 to interrupt0* 0 20 retryctr1mask masks retryctr1 to interrupt0* 0 21 pmc1mask if power management is enabled, masks pmc1 interrupt to interrupt0*, otherwise it is reserved (read only 0). 0 23:22 reserved. 24 pciarb0mask masks pciarb0 to interrupt0* 0 25 pciarb1mask masks pciarb1 to interrupt0* 0 table 395: interrupt0* main mask register, offset: 0x000c1c (continued) bits field name function initial value GT-96100A advanced communication controller 434 revision 1.0 31:26 reserved. 0 table 397: interrupt1* main mask register, offset: 0x000c24 bits field name function initial value 0 reserved 0 1 memoutmask masks memout interrupt to interrupt1* 0 2 dmaoutmask masks dmaout interrupt to interrupt1* 0 3 cpuoutmask masks cpuout interrupt to interrupt1* 0 4 dma0compmask masks dma0comp interrupt to interrupt1* 0 5 dma1compmask masks dma1comp interrupt to interrupt1* 0 6 dma2compmask masks dma2comp interrupt to interrupt1* 0 7 dma3compmask masks dma3comp interrupt to interrupt1* 0 8 t0expmask masks t0exp interrupt to interrupt1* 0 9 t1expmask masks t1exp interrupt to interrupt1* 0 10 t2expmask masks t2exp interrupt to interrupt1* 0 11 t3expmask masks t3exp interrupt to interrupt1* 0 12 masrderr0mask masks masrderr0 interrupt to interrupt1* 0 13 slvwrerr0mask masks slvwrerr0 interrupt to interrupt1* 0 14 maswrerr0mask masks maswrerr0 interrupt to interrupt1* 0 15 slvrderr0mask masks slvrderr0 interrupt to interrupt1* 0 16 addrerr0mask masks addrerr0 interrupt to interrupt1* 0 17 memerrmask masks memerr interrupt to interrupt1* 0 18 masabort0mask masks masabort0 interrupt to interrupt1* 0 19 tarabort0mask masks tarabort0 interrupt to interrupt1* 0 20 retryctr0mask masks retryctr0 interrupt to interrupt1* 0 21 pmc0mask if power management is enabled, masks pmc0 interrupt to interrupt1*, otherwise it masks cpuint interrupt to interrupt1* 0 25:22 cpuint masks cpuint interrupt to interrupt1* 0 31:26 reserved 0 table 396: interrupt0* high mask register, offset: 0x000c9c (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 435 table 398: interrupt1* high mask register, offset: 0x000ca4 bits field name function initial value 0 ether0summask masks ether0sum to interrupt1* 0 1 ether1summask masks ether1sum to interrupt1* 0 3:2 reserved. 0 4 sdmasummask masks sdmasum to interrupt1* 0 5 mpscsummask masks mpscsum to interrupt1* 0 6 ftdmsummask masks ftdmsum to interrupt1* 0 7 brgsummask masks brgsum to interrupt1* 0 8 gpp0summask masks gpp0sum to interrupt1* 0 9 gpp1summask masks gpp1sum to interrupt1* 0 10 gpp2summask masks gpp2sum to interrupt1* 0 11 reserved. 0 12 masrderr1mask masks masrderr1 to interrupt1* 0 13 slvwrerr1mask masks slvwrerr1 to interrupt1* 0 14 maswrerr1mask masks maswrerr1 to interrupt1* 0 15 slvrderr1mask masks slvrderr1 to interrupt1* 0 16 addrerr1mask masks addrerr1 to interrupt1* 0 17 reserved. 0 18 masabort1mask masks masabort1 to interrupt1* 0 19 tarabort1mask masks tarabort1 to interrupt1* 0 20 retryctr1mask masks retryctr1 to interrupt1* 0 21 pmc1mask if power management is enabled, masks pmc1 interrupt to interrupt1*. otherwise, it is reserved (read only 0). 0 23:22 reserved. 24 pciarb0mask masks pciarb0 to interrupt1* 0 25 pciarb1mask masks pciarb1 to interrupt1* 0 31:26 reserved. 0 GT-96100A advanced communication controller 436 revision 1.0 table 399: serial cause register, offset: 0x103a00 bits field name function initia l value 0 ether0sum ethernet port 0 interrupt summary logical or of all unmasked interrupt bits in the ethernet0_cause register. this bit is read-only. 0 1 ether1sum ethernet port 1interrupt summary logical or of all unmasked interrupt bits in the ethernet1_cause register. this bit is read-only. 0 3:2 reserved. 0 4 sdmasum sdma interrupt summary logical or of all unmasked bits in the sdma_cause register. this bit is read-only. 0 5 mpscsum mpsc interrupt summary logical or of all unmasked interrupt bits in the mpsc_cause regis- ters. this bit is read-only. 0 6 ftdmsum flextdm interrupt summary logical or of all unmasked interrupt bits in the ftdm_cause regis- ter. this bit is read-only. 0 7 brgsum baud rate generators interrupt summary logical or of all unmasked interrupt bits in the brg_cause regis- ter. this bit is read-only. 0 8 sdma0sum sdma0 interrupt summary logical or of unmasked bits [3:0] in the sdma_cause register. this bit is read-only. 0 9 mpsc0sum mpsc0 interrupt summary logical or of all unmasked interrupt bits in the mpsc0_cause reg- ister. this bit is read-only. 0 10 sdma1sum sdma1 interrupt summary logical or of unmasked bits [7:4] in the sdma_cause register. this bit is read-only. 0 GT-96100A advanced communication controller revision 1.0 437 11 mpsc1sum mpsc1 interrupt summary logical or of all unmasked interrupt bits in the mpsc1_cause reg- ister. this bit is read-only. 0 12 sdma2sum sdma2 interrupt summary logical or of unmasked bits [11:8] in the sdma_cause register. this bit is read-only. 0 13 mpsc2sum mpsc2 interrupt summary logical or of all unmasked interrupt bits in the mpsc2_cause reg- ister. this bit is read-only. 0 14 sdma3sum sdma2 interrupt summary logical or of unmasked bits [15:12] in the sdma_cause register. this bit is read-only. 0 15 mpsc3sum mpsc3 interrupt summary logical or of all unmasked interrupt bits in the mpsc3_cause reg- ister. this bit is read-only. 0 16 sdma4sum sdma4 interrupt summary logical or of unmasked bits [19:16] in the sdma_cause register. this bit is read-only. 0 17 mpsc4sum mpsc4 interrupt summary logical or of all unmasked interrupt bits in the mpsc4_cause reg- ister. this bit is read-only. 0 18 sdma5sum sdma5 interrupt summary logical or of unmasked bits [23:20] in the sdma_cause register. this bit is read-only. 0 19 mpsc5sum mpsc5 interrupt summary logical or of all unmasked interrupt bits in the mpsc5_cause reg- ister. this bit is read-only. 0 20 sdma6sum sdma6 interrupt summary logical or of unmasked bits [27:24] in the sdma_cause register. this bit is read-only. 0 table 399: serial cause register, offset: 0x103a00 (continued) bits field name function initia l value GT-96100A advanced communication controller 438 revision 1.0 21 mpsc6sum mpsc6 interrupt summary logical or of all unmasked interrupt bits in the mpsc6_cause reg- ister. this bit is read-only. 0 22 sdma7sum sdma7 interrupt summary logical or of unmasked bits [31:28] in the sdma_cause register. this bit is read-only. 0 23 mpsc7sum mpsc7 interrupt summary logical or of all unmasked interrupt bits in the mpsc7_cause reg- ister. this bit is read-only. 0 24 gpp0sum gpp0 interrupt summary logical or of all unmasked interrupt bits in the gpp0_cause regis- ter. this bit is read-only. 0 25 gpp1sum gpp1 interrupt summary logical or of all unmasked interrupt bits in the gpp1_cause regis- ter. this bit is read-only. 0 26 gpp2sum gpp2 interrupt summary logical or of all unmasked interrupt bits in the gpp2_cause regis- ter. this bit is read-only. 0 31:27 reserved. 0 table 400: serint0* mask register, offset: 0x103a80 bits field name function initial value 0 ether0summask mask ether0sum interrupt to serint0* 0 1 ether1summask mask ether1sum interrupt to serint0* 0 3:2 reserved. 0 4 sdmasummask mask sdmasum interrupt to serint0* 0 5 mpscsummask mask mpscsum interrupt to serint0* 0 6 ftdmsummask mask ftdmsum interrupt to serint0* 0 table 399: serial cause register, offset: 0x103a00 (continued) bits field name function initia l value GT-96100A advanced communication controller revision 1.0 439 7 brgsummask mask brgsum interrupt to serint0* 0 8 sdma0summask mask sdma0sum interrupt to serint0* 0 9 mpsc0summask mask mpsc0sum interrupt to serint0* 0 10 sdma1summask mask sdma1sum interrupt to serint0* 0 11 mpsc1summask mask mpsc1sum interrupt to serint0* 0 12 sdma2summask mask sdma2sum interrupt to serint0* 0 13 mpsc2summask mask mpsc2sum interrupt to serint0* 0 14 sdma3summask mask sdma3sum interrupt to serint0* 0 15 mpsc3summask mask mpsc3sum interrupt to serint0* 0 16 sdma4summask mask sdma4sum interrupt to serint0* 0 17 mpsc4summask mask mpsc4sum interrupt to serint0* 0 18 sdma5summask mask sdma5sum interrupt to serint0* 0 19 mpsc5summask mask mpsc5sum interrupt to serint0* 0 20 sdma6summask mask sdma6sum interrupt to serint0* 0 21 mpsc6summask mask mpsc6sum interrupt to serint0* 0 22 sdma7summask mask sdma7sum interrupt to serint0* 0 23 mpsc7summask mask mpsc7sum interrupt to serint0* 0 24 gpp0summask mask gpp0sum interrupt to serint0* 0 25 gpp1summask mask gpp1sum interrupt to serint0* 0 26 gpp2summask mask gpp2sum interrupt to serint0* 0 31:27 reserved. 0 table 401: serint1* mask register, offset: 0x103a88 bits field name function initial value 0 ether0summask mask ether0sum interrupt to serint1* 0 1 ether1summask mask ether1sum interrupt to serint1* 0 3:2 reserved. 0 4 sdmasummask mask sdmasum interrupt to serint1* 0 5 mpscsummask mask mpscsum interrupt to serint1* 0 table 400: serint0* mask register, offset: 0x103a80 (continued) bits field name function initial value GT-96100A advanced communication controller 440 revision 1.0 6 ftdmsummask mask ftdmsum interrupt to serint1* 0 7 brgsummask mask brgsum interrupt to serint1* 0 8 sdma0summask mask sdma0sum interrupt to serint1* 0 9 mpsc0summask mask mpsc0sum interrupt to serint1* 0 10 sdma1summask mask sdma1sum interrupt to serint1* 0 11 mpsc1summask mask mpsc1sum interrupt to serint1* 0 12 sdma2summask mask sdma2sum interrupt to serint1* 0 13 mpsc2summask mask mpsc2sum interrupt to serint1* 0 14 sdma3summask mask sdma3sum interrupt to serint1* 0 15 mpsc3summask mask mpsc3sum interrupt to serint1* 0 16 sdma4summask mask sdma4sum interrupt to serint1* 0 17 mpsc4summask mask mpsc4sum interrupt to serint1* 0 18 sdma5summask mask sdma5sum interrupt to serint1* 0 19 mpsc5summask mask mpsc5sum interrupt to serint1* 0 20 sdma6summask mask sdma6sum interrupt to serint1* 0 21 mpsc6summask mask mpsc6sum interrupt to serint1* 0 22 sdma7summask mask sdma7sum interrupt to serint1* 0 23 mpsc7summask mask mpsc7sum interrupt to serint1* 0 24 gpp0summask mask gpp0sum interrupt to serint1* 0 25 gpp1summask mask gpp1sum interrupt to serint1* 0 26 gpp2summask mask gpp2sum interrupt to serint1* 0 31:27 reserved. 0 table 402: ethernet0 cause register, offset: 0x084850 and ethernet0 mask register, offset: 0x084858 bits field name function initial value 0 rxbuffer rx buffer return 0 1 reserved. 0 2 txbufferhigh tx buffer for high priority queue. 0 table 401: serint1* mask register, offset: 0x103a88 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 441 3 txbufferlow tx buffer for low priority queue. 0 5:4 reserved. 0 6 txendhigh tx end for high priority queue. 0 7 txendlow tx end for low priority queue. 0 8 rxerror rx resource error. indicates a rx resource error event. 0 9 reserved. 0 10 txerrorhigh tx resource error for high priority queue. 0 11 txerrorlow tx resource error for low priority queue. 0 12 rxovr rx overrun 0 13 txudr tx underrun 0 27:14 reserved. 0 28 miiphystc mii phy status change. 0 29 smidone smi command done 0 30 reserved. 0 31 etherintsum ethernet interrupt summary this bit is a logical or of the (unmasked) bits [30:4] in the interrupt cause register. 0 table 403: ethernet1 cause register, offset: 0x088850 and ethernet1 mask register, offset: 0x088858 bits field name function initial value 31:0 various same as for ethernet0 cause register. 0 table 404: sdma cause register, offset: 0x103a10 and sdma mask register, offset: 0x103a90 bits field name function initial value 0 sdma0rxbuf sdma channel 0 rx buffer return indicates that sdma0 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 table 402: ethernet0 cause register, offset: 0x084850 and ethernet0 mask register, offset: 0x084858 (continued) bits field name function initial value GT-96100A advanced communication controller 442 revision 1.0 1 sdma0rxerr sdma channel 0 rx error indicates that a rx resource error occurred. 0 2 sdma0txbuf sdma channel 0 tx buffer return indicates that sdma0 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 3 sdma0txend sdma channel 0 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also set when tx retransmit limit is reached in hdlc mode. 0 4 sdma1rxbuf sdma channel 1 rx buffer return indicates that sdma1 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 5 sdma1rxerr sdma channel 1 rx error indicates that a rx resource error occurred. 0 6 sdma1txbuf sdma channel 1 tx buffer return indicates that sdma1 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 7 sdma1txend sdma channel 1 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also set when tx retransmit limit is reached in hdlc mode. 0 8 sdma2rxbuf sdma channel 2 rx buffer return indicates that sdma2 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 9 sdma2rxerr sdma channel 2 rx error indicates that a rx resource error occurred. 0 10 sdma2txbuf sdma channel 2 tx buffer return indicates that sdma2 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 11 sdma2txend sdma channel 2 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also, set when tx retransmit limit is reached in hdlc mode. 0 12 sdma3rxbuf sdma channel 3 rx buffer return indicates that sdma3 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 table 404: sdma cause register, offset: 0x103a10 and sdma mask register, offset: 0x103a90 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 443 13 sdma3rxerr sdma channel 3 rx error indicates that a rx resource error occurred. 0 14 sdma3txbuf sdma channel 3 tx buffer return indicates that sdma3 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 15 sdma3txend sdma channel 3 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also, set when tx retransmit limit is reached in hdlc mode. 0 16 sdma4rxbuf sdma channel 4 rx buffer return indicates that sdma4 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 17 sdma4rxerr sdma channel 4 rx error indicates that a rx resource error occurred. 0 18 sdma4txbuf sdma channel 4 tx buffer return indicates that sdma4 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 19 sdma4txend sdma channel 4 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also, set when tx retransmit limit is reached in hdlc mode. 0 20 sdma5rxbuf sdma channel 5 rx buffer return indicates that sdma5 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 21 sdma5rxerr sdma channel 5 rx error indicates that a rx resource error occurred. 0 22 sdma5txbuf sdma channel 5 tx buffer return indicates that sdma5 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 23 sdma5txend sdma channel 5 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also, set when tx retransmit limit is reached in hdlc mode. 0 24 sdma6rxbuf sdma channel 6 rx buffer return indicates that sdma6 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 table 404: sdma cause register, offset: 0x103a10 and sdma mask register, offset: 0x103a90 (continued) bits field name function initial value GT-96100A advanced communication controller 444 revision 1.0 25 sdma6rxerr sdma channel 6 rx error indicates that a rx resource error occurred. 0 26 sdma6txbuf sdma channel 6 tx buffer return indicates that sdma6 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 27 sdma6txend sdma channel 6 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also, set when tx retransmit limit is reached in hdlc mode. 0 28 sdma7rxbuf sdma channel 7 rx buffer return indicates that sdma7 rx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 29 sdma7rxerr sdma channel 7 rx error indicates that a rx resource error occurred. 0 30 sdma7txbuf sdma channel 7 tx buffer return indicates that sdma7 tx closed a descriptor and returned the associ- ated buffer to cpu ownership. 0 31 sdma7txend sdma channel 7 tx end indicates that a tx resource error occurred or that the tx dma moved to idle after a stop command. also, set when tx retransmit limit is reached in hdlc mode. 0 table 405: mpsc0 cause register, offset: 0x103a20 and mpsc0 mask register, offset: 0x103aa0 bits field name function initial value 0 mpsc0rx mpsc0 normal rx interrupt summary logical or of (unmasked) bits 4-7 below. this bit is read only. 0 1 mpsc0rxerr mpsc0 rx error interrupt summary logical or of (unmasked) bits 8-11 below. this bit is read only. 0 2 reserved. 0 3 mpsc0txerr mpsc0 tx error interrupt summary logical or of (unmasked) bits 13-15 below. this bit is read only. 0 table 404: sdma cause register, offset: 0x103a10 and sdma mask register, offset: 0x103a90 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 445 4 mpsc0rlsc mpsc0 rx line status change (from to idle) 0 5 mpsc0rhnt mpsc0 rx entered hunt state 0 6mpsc0rfsc/ mpsc0rcc mpsc0 rx flag status change (hdlc mode) mpsc0 received control character (bisync, uart modes) 0 7 mpsc0rcsc mpsc0 rx carrier sense change (dpll decoded carriers sense) 0 8 mpsc0rovr mpsc0 rx overrun 0 9 mpsc0rcdl mpsc0 rx carrier detect loss 0 10 mpsc0rckg mpsc0 rx clock glitch 0 11 mpsc0bper mpsc0 bisync protocol error (valid only in bisync mode) 0 12 mpsc0teidl mpsc0 tx entered idle state 0 13 mpsc0tudr mpsc0 tx underrun 0 14 mpsc0tctsl mpsc0 tx clear to send loss 0 15 mpsc0tckg mpsc0 tx clock glitch 0 31:16 reserved. 0 table 406: mpsc1 cause register, offset: 0x103a24 and mpsc1 mask register, offset: 0x103aa4 bits field name function initial value 31:0 various same as for mpsc0 cause register. 0 table 407: mpsc2 cause register, offset: 0x103a28 and mpsc2 mask register, offset: 0x103aa8 bits field name function initial value 31:0 various same as for mpsc0 cause register. 0 table 405: mpsc0 cause register, offset: 0x103a20 and mpsc0 mask register, offset: 0x103aa0 (continued) bits field name function initial value GT-96100A advanced communication controller 446 revision 1.0 table 408: mpsc3 cause register, offset: 0x103a2c and mpsc3 mask register, offset: 0x103aac bits field name function initial value 31:0 various same as for mpsc0 cause register. 0 table 409: mpsc4 cause register, offset: 0x103a30 and mpsc4 mask register, offset: 0x103ab0 bits field name function initial value 31:0 various same as for mpsc0 cause register. 0 table 410: mpsc5 cause register, offset: 0x103a34 and mpsc5 mask register, offset: 0x103ab4 bits field name function initial value 31:0 various same as for mpsc0 cause register. 0 table 411: mpsc6 cause register, offset: 0x103a38 and mpsc6 mask register, offset: 0x103ab8 bits field name function initial value 31:0 various same as for mpsc0 cause register. 0 table 412: mpsc7 cause register, offset: 0x103a3c and mpsc7 mask register, offset: 0x103abc bits field name function initial value 31:0 various same as for mpsc0 cause register. 0 GT-96100A advanced communication controller revision 1.0 447 table 413: flextdm cause register, offset: 0x103a40 and flextdm mask register, offset: 0x103ac0 bits field name function initial value 0 ftdm0rauxa flextdm0 rx interrupt from aux channel a 0 1 ftdm0rauxb flextdm0 rx interrupt from aux channel b 0 2 ftdm0rint flextdm0 rx interrupt (programmed in dual port ram) 0 3 ftdm0rsl flextdm0 rx synchronization loss 0 4 ftdm0tauxa flextdm0 tx interrupt from aux channel a 0 5 ftdm0tauxb flextdm0 tx interrupt from aux channel b 0 6 ftdm0tint flextdm0 tx interrupt (programmed in dual port ram) 0 7 ftdm0tsl flextdm0 tx synchronization loss 0 8 ftdm1rauxa flextdm1 rx interrupt from aux channel a 0 9 ftdm1rauxb flextdm1 rx interrupt from aux channel b 0 10 ftdm1rint flextdm1 rx interrupt (programmed in dual port ram) 0 11 ftdm1rsl flextdm1 rx synchronization loss 0 12 ftdm1tauxa flextdm1 tx interrupt from aux channel a 0 13 ftdm1tauxb flextdm1 tx interrupt from aux channel b 0 14 ftdm1tint flextdm1 tx interrupt (programmed in dual port ram) 0 15 ftdm1tsl flextdm1 tx synchronization loss 0 16 ftdm2rauxa flextdm2 rx interrupt from aux channel a 0 17 ftdm2rauxb flextdm2 rx interrupt from aux channel b 0 18 ftdm2rint flextdm2 rx interrupt (programmed in dual port ram) 0 19 ftdm2rsl flextdm2 rx synchronization loss 0 20 ftdm2tauxa flextdm2 tx interrupt from aux channel a 0 21 ftdm2tauxb flextdm2 tx interrupt from aux channel b 0 22 ftdm2tint flextdm2 tx interrupt (programmed in dual port ram) 0 23 ftdm2tsl flextdm2 tx synchronization loss 0 24 ftdm3rauxa flextdm3 rx interrupt from aux channel a 0 25 ftdm3rauxb flextdm3 rx interrupt from aux channel b 0 26 ftdm3rint flextdm3 rx interrupt (programmed in dual port ram) 0 27 ftdm3rsl flextdm3 rx synchronization loss 0 28 ftdm3tauxa flextdm3 tx interrupt from aux channel a 0 GT-96100A advanced communication controller 448 revision 1.0 29 ftdm3tauxb flextdm3 tx interrupt from aux channel b 0 30 ftdm3tint flextdm3 tx interrupt (programmed in dual port ram) 0 31 ftdm3tsl flextdm3 tx synchronization loss 0 table 414: brg cause register, offset: 0x103a48 and brg mask register, offset: 0x103ac8 bits field name function initial value 0 btr0 baud tuning 0 interrupt 0 1 btr1 baud tuning 1 interrupt 0 2 btr2 baud tuning 2 interrupt 0 3 btr3 baud tuning 3 interrupt 0 4 btr4 baud tuning 4 interrupt 0 5 btr5 baud tuning 5 interrupt 0 6 btr6 baud tuning 6 interrupt 0 7 btr7 baud tuning 7 interrupt 0 31:24 reserved. 0 table 415: gpp0 cause register, offset: 0x103a50 and gpp0 mask register, offset: 0x103ad0 bits field name function initial value 31:0 gpint[31:0] general purpose interrupt bits a bit in this cause register is set when the value latched in the gpd register bit is '0'. note: interrupts also occur when the associated gpc pin is con- figured as a functional input. 0 table 413: flextdm cause register, offset: 0x103a40 and flextdm mask register, offset: 0x103ac0 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 449 table 416: gpp1 cause register, offset: 0x103a54 and gpp1 mask register, offset: 0x103ad4 bits field name function initial value 31:0 gpint[63:32] general purpose interrupt bits a bit in this cause register is set when the value latched in the gpd register bit is '0'. note: interrupts also occur when the associated gpc pin is con- figured as a functional input. 0 table 417: gpp2 cause register, offset: 0x103a58 and gpp2 mask register, offset: 0x103ad8 bits field name function initial value 31:0 gpint[95:64] general purpose interrupt bits a bit in this cause register is set when the value latched in the gpd register bit is '0'. note: interrupts also occur when the associated gpc pin is con- figured as a functional input. 0 table 418: serr0* mask, pci_0 events offset: 0xc28 bits field name function initial value 0 addrerr0 mask bit. when this bit is set and the GT-96100A detects a parity error on pci_0 address lines, serr0* is asserted. 0x0 1 maswrerr0 mask bit. when this bit is set and the GT-96100A detects a parity error during a pci_0 master write operation, serr0* is asserted. 0x0 2 masrderr0 mask bit. when this bit is set and the GT-96100A detects a parity error during a pci_0 master read operation, serr0* is asserted. 0x0 3 memerr mask bit. when this bit is set and a memory parity error has been detected, serr0* is asserted. 0x0 4 masabor0t mask bit. when this bit is set and the GT-96100A performs a pci_0 master abort, serr0* is asserted. 0x0 GT-96100A advanced communication controller 450 revision 1.0 5 tarabort0 mask bit. when this bit is set and the GT-96100A detects a pci_0 target abort, serr0* is asserted. 0x0 31:6 reserved 0x0 table 418: serr0* mask, pci_0 events offset: 0xc28 (continued) bits field name function initial value GT-96100A advanced communication controller revision 1.0 451 table 419: serr1* mask, pci_1 events offset: 0xca8 (reserved if configured for only pci_0) bits field name function initial value 0 addrerr1 mask bit. when this bit is set and the GT-96100A detects a parity error on the pci_1 address lines, serr1* is asserted. 0x0 1 maswrerr1 mask bit. when this bit is set and the GT-96100A detects a parity error during a pci_1 master write operation, serr1* is asserted. 0x0 2 masrderr1 mask bit. when this bit is set and the GT-96100A detects a parity error during a pci_1 master read operation, serr1* is asserted. 0x0 3 memerr mask bit. when this bit is set and a memory parity error has been detected, serr1* is asserted. 0x0 4 masabort1 mask bit. when this bit is set and the GT-96100A performs a pci_1 master abort, serr1* is asserted. 0x0 5 tarabort1 mask bit. when this bit is set and the GT-96100A detects a pci_1 target abort, serr1* is asserted. 0x0 31:6 reserved 0x0 GT-96100A advanced communication controller 452 revision 1.0 22. r eset c onfiguration the GT-96100A must acquire some knowledge about the system before it is configured by the software. special modes of operation are sampled on reset in order to enable the GT-96100A to function as required. certain pins must be pulled up to vcc3.3 or down to gnd (4.7k ohm recommended) externally to accomplish this. the following configuration pins are continuously sampled from rst* assertion until three tclk cycles after rst* is deasserted. this does not apply to frame1*/req64* that requires zero hold time in respect to reset rise (as defined in pci spec). note: rst* must be de-asserted for at least 10 pclk cycles before any cpu transactions are generated. table 420: reset configuration pin configuration function dadr[2], frame1*/req64*: pci bus configuration 00-only pci_0 is used as 64-bit. 01-only pci_0 is used as 32-bit, pci_1 is not used. 10-reserved. 11-both pci_0 and pci_1 are used as 32-bit. interrupt0*: cpu data endianess 0-big endian 1-little endian ready*, cstiming* multi-GT-96100A address id 00-gt responds to sysad[26,25]= 00 01-gt responds to sysad[26,25]= 01 10-gt responds to sysad[26,25]= 10 11- gt responds to sysad[26,25]= 11 note: boot GT-96100A should be programmed to 11. banksel[0]: pci class code default select 0-memory controller (0x580) 1-network controller (0x280) dadr[10]: multiple GT-96100A support 0-not supported. 1-supported. dadr[9]: 66 mhz pci 0-disable. 1-enable. dadr[8]: i 2 o support 0-enable. 1-disable. GT-96100A advanced communication controller revision 1.0 453 dadr[7]: uma support 0- 1- enable - dmareq[0]*/mreq* functions as mreq*. disable - dmareq[0]*/mreq* functions as dmareq[0]*. dadr[6]: programming conditional pci retry 0- 1- enable. disable. dadr[5]: expansion rom enable 0- 1- enable. disable. dadr[4:3]: device boot bus width (controlled by bootcs*) and cs[3]* device width. 00- 01- 10- 11- 8 bits 16 bits 32 bits 64 bits dadr[0]: autoload 0- 1- enable. disable. sdqm[1]: pci_1 power management 0- 1- disable. enable. sdqm[0]: pci_0 power management 0- 1- disable. enable. dmareq[3]* duplicate ale 0- 1- do not duplicate ale. duplicate ale output on adp[1] (no ecc in system). dmareq[1]* duplicate sdram control signals 0- 1- do not duplicate sras*, scas* and dwr*. duplicate sras*, scas* and dwr* on adp[7], adp[6] and adp[3] (no ecc in system). adp[7:4] reserved design in the option to pull-up or pull-down these pins. table 420: reset configuration (continued) pin configuration function GT-96100A advanced communication controller 454 revision 1.0 dadr[1] reserved must pull low during reset. dmareq[2]* reserved must pull low during reset. sdqm[2] reserved must pull low during reset. sdqm[3] reserved must pull low during reset. table 420: reset configuration (continued) pin configuration function GT-96100A advanced communication controller revision 1.0 455 23. c onnecting the m emory c ontroller to sdram and d evices in order to connect the memory (sdram and devices), follow the pin connections for the appropriate sdram and devices listed in this section?s tables. 23.1 sdram the GT-96100A supports both 64-bit and 32-bit sdram. table 421: 64-bit sdram connection connect... to... sdram address dadr[12:0] a[10:0] a[11] (64/128/256 mbit only) a[12] (256 mbit only) sdram bank address banksel[1:0] ba0 ba1 (64/128/256 mbit only) sdram data ad[63:0] d[63:0], sdram data pins sdram control pins sras* scas* dwr* 1 1. sras*, scas*, and dwr* can be duplicated on adp[7], adp[6] and adp[3] if programmed on reset. sdram row address strobe sdram column address strobe write enable chip selects scs[0]* scs[1]* scs[2]* scs[3]* chip select, bank 0 chip select, bank 1 chip select, bank 2 chip select, bank 3 byte enables sdqm[0]* sdqm[1]* sdqm[2]* sdqm[3]* sdqm[4]* sdqm[5]* sdqm[6]* sdqm[7]* d[7:0] byte enable d[15:8] byte enable d[23:16] byte enable d[31:24] byte enable d[39:32] byte enable d[47:40] byte enable d[55:48] byte enable d[63:56] byte enable ecc bits adp[7:0] d[63:0] ecc byte clock same clock output used for tclk clock input GT-96100A advanced communication controller 456 revision 1.0 23.2 devices the GT-96100A supports 64-, 32-, 16- and 8-bit devices. table 422: 32-bit sdram connection connect... to... sdram address dadr[11:0] a[10:0] a[11] (64/128 mbit only) sdram bank address banksel[1:0] ba0 ba1 (64/128 mbit only) sdram even data sdram odd data ad[31:0] ad[63:32] even d[31:0] sdram data pins odd d[31:0] sdram data pins sdram control pins sras* scas* dwr* 1 1. sras*, scas*, and dwr* can be duplicated on adp[7], adp[6] and adp[3] if programmed on reset. sdram row address strobe sdram column address strobe write enable chip selects scs[0]* scs[1]* scs[2]* scs[3]* chip select, bank 0 chip select, bank 1 chip select, bank 2 chip select, bank 3 byte enables sdqm[0]* sdqm[1]* sdqm[2]* sdqm[3]* sdqm[4]* sdqm[5]* sdqm[6]* sdqm[7]* even d[7:0] byte enable even d[15:8] byte enable even d[23:16] byte enable even d[31:24] byte enable odd d[7:0] byte enable odd d[15:8] byte enable odd d[23:16] byte enable odd d[31:24] byte enable ecc bits not supported for 32-bit sdram. clock same clock output used for tclk. clock input table 423: 64-bit devices connection connect... to... device address badr[2:0] ad[31:6] ale latch outputs to the device?s lsb address bits. address latch inputs address le device address bits [28:3] GT-96100A advanced communication controller revision 1.0 457 device data ad[63:0] device data pins [63:0] device control pins ale ad[41:32] control latch bit[41] output control latch bit[40] output control latch bit[39:36] outputs control latch bit[35:32] outputs control latch le control latch inputs becomes devrw* becomes bootcs* becomes cs[3:0]* becomes dmaack[3:0]* write strobes wr[0]* wr[1]* wr[2]* wr[3]* wr[4]* wr[5]* wr[6]* wr[7]* d[7:0] write strobe d[15:8] write strobe d[23:16] write strobe d[31:24] write strobe d[39:32] write strobe d[47:40] write strobe d[55:48] write strobe d[63:56] write strobe ecc bits not supported for devices. table 424: 32-bit devices connection connect... to... device address badr[2:0] ad[31:5] ale latch outputs to the device?s lsb address bits. address latch inputs address le device address bits [29:3] device data ad[31:0] ad[63:32] device even data pins [31:0] device odd data pins[31:0] device control pins ale ad[41:32] control latch bit[41] output control latch bit[40] output control latch bit[39:36] outputs control latch bit[35:32] outputs control latch le control latch inputs becomes devrw* becomes bootcs* becomes cs[3:0]* becomes dmaack[3:0]* table 423: 64-bit devices (continued) connection connect... to... GT-96100A advanced communication controller 458 revision 1.0 write strobes wr[0]* wr[1]* wr[2]* wr[3]* wr[4]* wr[5]* wr[6]* wr[7]* even d[7:0] write strobe even d[15:8] write strobe even d[23:16] write strobe even d[31:24] write strobe odd d[7:0] write strobe odd d[15:8] write strobe odd d[23:16] write strobe odd d[31:24] write strobe ecc bits not supported for devices. table 425: 16-bit devices connection connect... to... device address badr[2:0] ad[31:4] ale latch outputs to the device?s lsb address bits. address latch inputs address le device address bits [30:3] device data ad[15:0] ad[47:32] device even data pins [15:0] device odd data pins[15:0] device control pins ale ad[41:32] control latch bit[41] output control latch bit[40] output control latch bit[39:36] outputs control latch bit[35:32] outputs control latch le control latch inputs becomes devrw* becomes bootcs* becomes cs[3:0]* becomes dmaack[3:0]* write strobes wr[0]* wr[1]* wr[4]* wr[5]* even d[7:0] write strobe even d[15:8] write strobe odd d[7:0] write strobe odd d[15:8] write strobe ecc bits not supported for devices. table 424: 32-bit devices (continued) connection connect... to... GT-96100A advanced communication controller revision 1.0 459 table 426: 8-bit devices connection connect... to... device address badr[2:0] ad[31:3] ale latch outputs to the device?s lsb address bits. address latch inputs address le device address bits [31:3] device data ad[7:0] ad[39:32] device even data pins [7:0] device odd data pins[7:0] device control pins ale ad[41:32] control latch bit[41] output control latch bit[40] output control latch bit[39:36] outputs control latch bit[35:32] outputs control latch le control latch inputs becomes devrw* becomes bootcs* becomes cs[3:0]* becomes dmaack[3:0]* write strobes wr[0]* wr[4]* even d[7:0] write strobe odd d[7:0] write strobe ecc bits not supported for devices. GT-96100A advanced communication controller 460 revision 1.0 24. jtag i nterface 24.1 ieee standard 1149.1 the GT-96100A supports test mode operation through it?s jtag boundary scan interface to enable board testing. the jtag interface is ieee 1149.1 standard compliant. it supports mandatory and optional boundary scan instructions. 24.2 tap controller the test access port (tap) is constructed with a 5-pin interface and a 16-state finite state machine (fsm), as defined by ieee jtag standard 1149.1. to place the GT-96100A in functional mode, the jtag interface must be disabled by resetting the jtag state machine. according to the ieee 1149.1 standard, the jtag state machine is not reset when the GT-96100A reset is asserted. the jtag state machine can only be reset by one of the following methods: ? asserting trst* (jtag[4]). ? by setting tms (jtag[1]) for at least five tck (jtag[0]) cycles. to place the GT-96100A in the boundary scan test mode, the jtag state machine must be moved to it's control states. the tms & tdi inputs control the state transitions of the jtag state machine, as specified in the 1149.1 standard. the jtag state machine has various states for shifting instructions to the instruction register and for shifting data to and from the boundary scan, identification, or bypass registers. note: although the jtag state machine is not reset, the GT-96100A reset must be de-asserted (pulled up) when the GT-96100A is in the boundary scan test mode. in order to meet this requirement, the bsdl file defines the reset within a compliant pattern. GT-96100A advanced communication controller revision 1.0 461 24.3 instruction register (ir) the instruction register (ir) is a 4-bit two-stage register. it contains the command that is shifted in when the tap fsm is in the shift-ir state. when the tap fsm is in the capture-ir state, the ir outputs all four bits in parallel. the GT-96100A supports the following instructions: note: bi-directional pins can be programmed to be either input or output, depending on their control bit in the boundary scan register. 24.4 bypass register (br) the bypass register (br) is a one-bit serial shift register that connects tdi to tdo when the ir holds the bypass command, and the tap fsm is in the shift-dr state. data that is driven on the tdi input pin is shifted out one cycle later on the tdo output pin. the bypass register is loaded with "0" when the tap fsm is in the capture-dr state. 24.5 jtag scan chain the jtag scan chain is a serial shift register that is used to sample and drive all of the GT-96100A pins during the jtag tests. it is a 216-bit deep shift register in the GT-96100A, thereby allowing it to sequentially access all of the data pins. for further details, go to jtag scan chain in bsdl format ( hash://www.galileot.com/library/ raclib.htm ) for a full description. table 427: supported jtag instructions instruction code description highz 0011 select the bypass register between tdi and tdo. sets the GT-96100A output pins to high-impedance state. idcode 0010 selects the identification register between tdi and tdo. this 32-bit register is used to identify the GT-96100A device. see table 428 extest 0000 selects the boundary scan register between tdi and tdo. output boundary scan register cells drive the output pins of the GT-96100A. input boundary scan register cell sample the input pin of the GT-96100A. sample/pre- load 0001 selects the boundary scan register between tdi and tdo. sample input pins of the GT-96100A to input boundary scan register cells. preload output boundary scan register cells with the boundary scan register value. bypass 1111 selects the single bit bypass registers between tdi and tdo. this allows for rapid data movement through an untested device. GT-96100A advanced communication controller 462 revision 1.0 24.6 id register the id register is a 32-bit deep serial shift register. the id register is loaded with vendor and device informa- tion when the tap fsm is in the capture-dr state. in the GT-96100A, the id register is loaded with "00011001011000010000000101010111" during capture_dr. the identification code format of the id register is shown in table 428 which describes the various id code fields. when the jtag interface is not connected in a jtag chain on the board: ? it's input pins must be pulled to vcc3.3, or gnd (4.7k ohm recommended). ? it's output pin (tdo) must be left unconnected. jtag tms & tdi input pins must be pulled high, and tclk & trst* input pins must be pulled low. table 428: idcode register map bits value description 31:28 0010 version 27:12 1001011001010011 part number 11:1 00010101011 manufacturer id 0 1 mandatory GT-96100A advanced communication controller revision 1.0 463 25. b ig and l ittle e ndian 25.1 background note: for a description of big and little endian and how it is used in galileo technology system controllers, go to endianess explained! ( http://www.galileot.com/library/syslib.htm ) on the galileo technology web- site. there are three bits in the GT-96100A which control byte swapping on the cpu and pci interfaces. one bit is located in the cpu interface configuration register (0x000) bit 12. the other two bits are in pci internal com- mand register (0xc00) bits 0 and 16. all these bits are given the same value as sampled at reset on interrupt0* pin. these bits can also be pro- grammed after reset is de-asserted. if all bits are set to 1, the GT-96100A assumes little-endian data format and no byte swapping is done within the device. additionally, there are three word-swap bits in GT-96100A which controls 32-bit word swap on access to/ from pci: ? bit 10 controls pci master interface word swap. ? bit 11 controls pci target interface word swap when accessed through non-swap bars. ? bit 12 controls pci target interface word swap when accessed through swap bars. since the pci bus is 32-bit wide and the GT-96100A data path is 64-bit wide, byte swap is not good enough in case of working in a big endian pci bus configuration. these three bits are used for endianess compensation for this case. on top of the above, the GT-96100A supports byte swapping on serial data transferred between the communica- tion unit agents and memory/pci. each of the serial dma channels has two configuration bits associated with it that control byte swapping - one bit controls swapping of incoming (receive) data, and the other bit controls swapping of outgoing (transmit) data. refer to the ethernet and sdma sections for more details about serial dma configuration options. 1 the nomenclature for this section is shown in table 429 . 1. dma descriptors that are used by the serial dma channels are not considered data, and therefore are not affected by the sett ing of receive/trans- mit swap bits in the dma configuration registers. descriptors swapping is controlled via one bit in the ciu configuration regis ter. refer to ciu section for details. GT-96100A advanced communication controller 464 revision 1.0 25.1.1 bit 12 of the cpu interface configuration register bit 12 of the cpu interface configuration register (0x000) affects the following: ? setting this bit to 1 (little-endian mode) means there is no byte swapping within the cpu interface unit on any data transfer. ? setting this bit to 0 (big endian mode) means that byte swapping takes place on data transfers from cpu to the GT-96100A internal registers (including configuration data register, offset 0xcfc). no byte swapping takes place on data transfers for which the source/target is external. 25.1.2 bits 0 and 16 of the pci internal command register bit 0 of the pci internal command register (0xc00) controls byte swapping of GT-96100A pci master interface. bit 16 controls byte swapping of GT-96100A pci target interface. these bits affect the following: ? setting these bits to 1 means there is no byte swapping within the pci interface unit on any data transfer. ? setting these bits to 0 means that no byte swapping takes place on data transfers from pci to/from the GT-96100A internal registers. byte swapping does take place on data transfers for which the source/tar- get is external 25.1.3 bits 10-12 of the pci internal command register setting these bits to 0 means there is no word swapping. setting these bits to 1 means that no word swapping takes place on data transfers from pci to/from the gt- 96100a internal registers. word swapping does take place on data transfers for which the source/target is exter- nal. note: only the 32-bit pci interface supports word swapping. table 429: nomenclature name definition w, word 32-bits of data, r4600 terminology dw, double word 64-bits of data, r4600 terminology even address address of which a[2] == 0 in little-endian format, this address points to the least significant w of a dw. in big-endian format, this address points to the most significant w of a dw. odd address address of which a[2] == 1. in little-endian format, this address points to the most significant w of a dw. in big-endian format, this address points to the least significant w of a dw. even word least significant w of a dw. odd word most significant w of a dw. GT-96100A advanced communication controller revision 1.0 465 25.2 configuring a system for big and little endian table 430 shows the basic combinations of the resources and swapping bits with sample data. ? cpu bit = bit 12 of the cpu interface configuration register (0x000). ? pci byte swap bit = bits 0 and 16 of the pci internal command register (0xc00). ? pci word swap bit = bits 10-12 of the pci internal command register (0xc00). note: the sample data is 0x04030201. table 430: configuring for big and little endian resource swap bits (cpu bit: pci byte swap bit: pci word swap bit) 110 001 010 101 internal registers (cpu access) 04030201 01020304 01020304 04030201 internal registers (pci access) 04030201 04030201 04030201 04030201 internal pci configuration registers (cpu access) 04030201 01020304 01020304 04030201 internal pci configuration registers (pci access) 04030201 04030201 04030201 04030201 external pci configuration registers 04030201 04030201 01020304 01020304 memory (dram and devices) (cpu access) 04030201 04030201 04030201 04030201 memory (dram and devices) (pci access) 04030201 01020304 04030201 01020304 cpu to pci (except external pci configuration regis- ters) 04030201 01020304 04030201 01020304 GT-96100A advanced communication controller 466 revision 1.0 26. u sing the GT-96100A w ithout the cpu i nterface table 431 lists the pins that must be strapped when the GT-96100A is used without the cpu interface (i.e., pci memory controller only). note: rst* and tclk must always be connected in any system. each pin must be strapped with a separate resistor unless otherwise noted. table 431: cpu-less pin strapping pin strapping 1 1. galileo technology recommends using 4.7kohm resistors. validout* pulled up to vcc through a resistor. release* pulled up to vcc through a resistor. sysad[63:0] 2 2. sysad[63:0] can be pulled up through a single resistor instead of 64 separate resistors. pulled up to vcc through a resistor. syscmd[8:0] 3 3. syscmd[8:0] can be pulled up through a single resistor instead of 9 separate resistors. pulled up to vcc through a resistor. sysadc[8:0] no connect. validin* no connect. wrrdy* no connect. interrupt* sampled at reset, see section 22. ?reset configuration? on page 452 . hit pulled down to gnd. sctce* pulled up to vcc. GT-96100A advanced communication controller revision 1.0 467 27. u sing the GT-96100A in d ifferent pci c onfigurations the pci interface of the GT-96100A can be used in 4 different modes: ?no pci. ? pci_0 as 32-bit pci. ? pci_0 and pci_1 as 32-bit pci. ? pci_0 as 64-bit pci. table 432 lists what must be done with the pins when the GT-96100A is used without any pci interface. note: rst* must be connected. most pins should be strapped high or low through a resistor. galileo tech- nology recommends using 4.7 kohm resistors. table 432: no pci interface pin pin usage vref0 vref0 pclk0 pulled up to vcc through a resistor. devsel0* pulled up to vcc through a resistor. stop0* pulled up to vcc through a resistor. par0 no connect. perr0* pulled up to vcc through a resistor. frame0* pulled up to vcc through a resistor. irdy0* pulled up to vcc through a resistor. trdy0* pulled up to vcc through a resistor. gnt0* pulled down to gnd through a resistor. idsel0 pulled down to gnd through a resistor. serr0* pulled up to vcc through a resistor. req0* no connect. int0* pulled up to vcc through a resistor. lock0* pulled up to vcc through a resistor. pad0[31:0] no connect. cbe0[3:0]* no connect. vref1 tie directly to 3v or 5v power plane. pclk1 pulled up to vcc through a resistor. devsel1*/ack64* pulled up to vcc through a resistor. stop1* pulled up to vcc through a resistor. par1/par64 no connect. GT-96100A advanced communication controller 468 revision 1.0 table 433 lists what must be done with the pins when the GT-96100A is used with pci_0 as a 32-bit pci inter- face only (i.e., no pci_1). note: when the GT-96100A is configured to a single 32-bit pci_0 interface, the GT-96100A drives all pci_1 interface signals to a random value. therefore, there is no need to put pull ups or pull downs on pci_1 interface signals. perr1* pulled up to vcc through a resistor. frame1*/req64* pulled up to vcc through a resistor. irdy1* pulled up to vcc through a resistor. trdy1* pulled up to vcc through a resistor. gnt1* pulled down to gnd through a resistor. idsel1 pulled down to gnd through a resistor. serr1* pulled up to vcc through a resistor. req1* no connect. pad1[31:0]/pad0[63:32] no connect. cbe1[3:0]*/cbe0[7:4]* no connect. table 433: pci_0 as 32-bit pci only pin pin usage vref0 vref0 pclk0 pclk0 devsel0* devsel0* stop0* stop0* par0 par0 perr0* perr0* frame0* frame0* irdy0* irdy0* trdy0* trdy0* gnt0* gnt0* idsel0 idsel0 serr0* serr0* req0* req0* table 432: no pci interface (continued) pin pin usage GT-96100A advanced communication controller revision 1.0 469 table 434 lists what must be done with the pins when the GT-96100A is used with pci_0 as a 32-bit pci inter- face and pci_1 as a 32-bit pci interface. int0* int0* lock0* lock0* pad0[31:0] pad0[31:0] cbe0[3:0]* cbe0[3:0]* vref1 tie directly to 3v or 5v power plane. pclk1 pulled up to vcc through a resistor. devsel1*/ack64* pulled up to vcc through a resistor. stop1* pulled up to vcc through a resistor. par1/par64 no connect. perr1* pulled up to vcc through a resistor. frame1*/req64* pulled up to vcc through a resistor. irdy1* pulled up to vcc through a resistor. trdy1* pulled up to vcc through a resistor. gnt1* pulled down to gnd through a resistor or pulled up to vcc through a resistor. idsel1 pulled down to gnd through a resistor. serr1* pulled up to vcc through a resistor. req1* no connect. pad1[31:0]/pad0[63:32] no connect. cbe1[3:0]*/cbe0[7:4]* no connect. table 433: pci_0 as 32-bit pci only (continued) pin pin usage GT-96100A advanced communication controller 470 revision 1.0 table 434: pci_0 as 32-bit pci and pci_1 as 32-bit pci pin pin usage vref0 vref0 pclk0 pclk0 devsel0* devsel0* stop0* stop0* par0 par0 perr0* perr0* frame0* frame0* irdy0* irdy0* trdy0* trdy0* gnt0* gnt0* idsel0 idsel0 serr0* serr0* req0* req0* int0* int0* lock0* lock0* pad0[31:0] pad0[31:0] cbe0[3:0]* cbe0[3:0]* vref1 vref1 pclk1 pclk1 devsel1*/ack64* devsel1* stop1* stop1* par1/par64 par1 perr1* perr1* frame1*/req64* frame1* irdy1* irdy1* trdy1* trdy1* gnt1* gnt1* idsel1 idsel1 serr1* serr1* req1* req1* GT-96100A advanced communication controller revision 1.0 471 table 435 lists what must be done with the pins when the GT-96100A is used with pci_0 as a 64-bit pci inter- face only (i.e. no pci_1). pad1[31:0]/pad0[63:32] pad1[31:0] cbe1[3:0]*/cbe0[7:4]* cbe1[3:0]* table 435: pci_0 as 64-bit pci only pin pin usage vref0 vref0 pclk0 pclk0 devsel0* devsel0* stop0* stop0* par0 par0 perr0* perr0* frame0* frame0* irdy0* irdy0* trdy0* trdy0* gnt0* gnt0* idsel0 idsel0 serr0* serr0* req0* req0* int0* int0* lock0* lock0* pad0[31:0] pad0[31:0] cbe0[3:0]* cbe0[3:0]* vref1 tie directly to 3v or 5v power plane (same as vref0). pclk1 tie directly to pclk0. devsel1*/ack64* ack64* stop1* pulled up to vcc through a resistor. par1/par64 par64 perr1* pulled up to vcc through a resistor. table 434: pci_0 as 32-bit pci and pci_1 as 32-bit pci (continued) pin pin usage GT-96100A advanced communication controller 472 revision 1.0 frame1*/req64* req64* irdy1* pulled up to vcc through a resistor. trdy1* pulled up to vcc through a resistor. gnt1* pulled up to vcc through a resistor. idsel1 pulled down to gnd through a resistor. serr1* pulled up to vcc through a resistor. req1* no connect. pad1[31:0]/pad0[63:32] pad0[63:32] cbe1[3:0]*/cbe0[7:4]* cbe0[7:4]* table 435: pci_0 as 64-bit pci only (continued) pin pin usage GT-96100A advanced communication controller revision 1.0 473 28. p hased l ocked l oop (pll) a pplication n otes note: future revisions of this datasheet will contain new information and guidelines about using pll. the GT-96100A contains a phase locked loop (pll) logic. it is used to improve ac timing of the GT-96100A tclk output signals. the following sections describe the special care the pll requires from the system designer. 28.1 pll power supply the GT-96100A?s internal pll has a separate power supply. there are two dedicated pins for this purpose - vccpll and vsspll. see section 33. ?pinout table, 492 pin bga? on page 533 for exact pin numbers. these analog power supplies must be isolated from the digital power supply pads and be noise filtered. the internal pll has two parallel capacitors values and two serial resistors used for vccpll and vsspll, see figure 79 . the values for the capacitors are 0 ? and 4.7 ? , respectively. the two resistors have a value of 1nf and 100nf, respectively. figure 78: filtering circuit note: at this stage, the above recommendations are based on simulations. galileo uses the above values for testing the GT-96100A. however, some changes to the above values might be required due to difference in package and the physical design of the devices. figure 79: resistor and capacitor values for vccpll and vsspll +2.5v gnd vsspll vccpll lqg21nr27k10 lqg21nr27k10 2 1 22ohm +/-5% 0603 2 1 22ohm +/-5% 0603 10uf +/-10% size b 0.1uf +/-10% 0603 1nf +/-10% 0603 vsspll vccpll 1 nf 100 nf 0 ? 4.7 ? gnd 2.5v=vcc GT-96100A advanced communication controller 474 revision 1.0 note: the capacitors and the resistor must be located as close as possible to the GT-96100A and only have a minimum distance between them. also, the capacitors must be assembled so that the 1nf capacitor is closest to the GT-96100A. 28.2 pll characteristics pll maximum pull-in time plus locking time is 0.5 ms. this means that the reset pin must be kept asserted for at least 0.5ms after tclk is on. GT-96100A advanced communication controller revision 1.0 475 29. s ystem c onfigurations 29.1 minimal system configuration ? low cost rv4650 cpu ? 32-bit sdram ? 8-bit boot eprom ? 32-bit pci figure 80: minimal system configuration or rv4650 GT-96100A 32 pci pci i/o pci i/o 32 sdram scas*, sras*, dwr* sdqm[3:0]* scs[0]* dadr[11:0] latch (373) boot rom dev_adr[21:0] cs* bootcs* cstiming* dadr[2:0] 8 64 adp[3:0] GT-96100A advanced communication controller 476 revision 1.0 29.2 typical system configuration ? support for rv4700/5260 cpu. ? support for 16-bit devices. ? support for 64-bit sdram. ? two 32-bit pci buses (3.3 and 5v support). figure 81: typical system configuration or rv4700/ 5260 GT-96100A 32 3.3v pci master slave 64 scas*, sras*, dwr* sdqm[7:0]* scs[1:0]* dadr[11:0] latch (373) boot flash dev_adr[21:0] cs* bootcs* cstiming* dadr[2:0] 16 64 adp[7:0] sdram 32 master slave 5v pci GT-96100A advanced communication controller revision 1.0 477 29.3 high performance system ? support for rv5000/5270 cpu. ? support for 2nd level cache. ? support for 64-bit devices. ? support for 64-bit pci. ? multiple banks of sdram. ? buffer used for large ad loading. figure 82: high performance system bi-directional buffer or rv5000/ 5270 GT-96100A 64 scas*, sras*, dwr* sdqm[7:0]* scs[3:0]* dadr[11:0] latch (373) boot flash dev_adr[21:0] cs* bootcs* cstiming* dadr[2:0] 64 adp[7:0] sdram 64 master slave l2 cache l2 cache control sctce*, scdoe*, scword[1:0], hit device or cs* cstiming* cs[0]* 64 16 wr[7:0]* GT-96100A advanced communication controller 478 revision 1.0 30. r egister t ables the GT-96100A?s internal registers are accessed by the cpu or from the pci bus. the registers are memory-mapped for the cpu and memory- or i/o-mapped for the pci. the registers? address is comprised of the value in the internal space decode register and the register offset. the value in the internal space decode register [14:0] is matched against bits [35:21] of the actual address; therefore, this value must be the actual address bits [35:21] shifted right once. for example, to access ?channel 0 dma byte count? register (offset 0x800) immediately after reset: ? the full address is the default value in the internal space decode register; ? this value is 0x0a0 shifted left once, which gives 0x140, two zero?s and the offset 0x800, to become a 32-bit address of 0x14000800. the location of the registers in the memory space can be changed by changing the value programmed into the internal space decode register. for example, after changing the value in the internal space decode register by writing to 0x14000068 a value of 0bd, an access to the ?channel 0 dma byte count? register is with 0x17a00800. when writing to the internal registers from the pci with byte enable = 0xf, the write is ignored (as per pci spec- ifications). if a write occurs to the following registers with at least one cbe* pin asserted, the entire 32-bit word is written: ? cpu interface ? processor address space decoders ? device address space decoders ? all sdram and device registers ? all dma registers ? all communication unit registers ? timer/counter the following internal registers are cbe* sensitive: ? pci internal registers ? pci configuration registers ? interrupt registers 30.1 access to on-chip pci configuration space registers an access from the cpu to one of the GT-96100A pci configuration registers is performed differently than accesses to all other registers. the access is performed indirectly by writing the pci configuration register offset into the configuration address register and then reading, or writing, the data from/to the configuration data reg- ister. for example, to read data from the status and command register, the register offset ?0x004? is written into the configuration address register, offset 0xcf8 (or full address from the previous example 0xbd000cf8). then, read- ing from the configuration data register (offset 0xcfc), returns the data of the status and command register. GT-96100A advanced communication controller revision 1.0 479 30.2 register maps table 436: cpu registers map description offset page number cpu configuration cpu interface configuration 0x000000 page 85 multi-gt register 0x000120 page 87 cpu address decode scs[1:0]* low decode address 0x000008 page 87 scs[1:0]* high decode address 0x000010 page 87 scs[3:2]* low decode address 0x000018 page 88 scs[3:2]* high decode address 0x000020 page 88 cs[2:0]* low decode address 0x000028 page 88 cs[2:0]* high decode address 0x000030 page 88 cs[3]* & boot cs* low decode address 0x000038 page 88 cs[3]* & boot cs* high decode address 0x000040 page 89 pci_0 i/o low decode address 0x000048 page 89 pci_0 i/o high decode address 0x000050 page 89 pci_0 memory 0 low decode address 0x000058 page 89 pci_0 memory 0 high decode address 0x000060 page 89 pci_0 memory 1 low decode address 0x000080 page 90 pci_0 memory 1 high decode address 0x000088 page 90 pci_1 i/o low decode address 0x000090 page 90 pci_1 i/o high decode address 0x000098 page 90 pci_1 memory 0 low decode address 0x0000a0 page 90 pci_1 memory 0 high decode address 0x0000a8 page 91 pci_1 memory 1 low decode address 0x0000b0 page 91 pci_1 memory 1 high decode address 0x0000b8 page 91 internal space decode 0x000068 page 91 scs[1:0]* address remap 0x0000d0 page 91 scs[3:2]* address remap 0x0000d8 page 92 cs[2:0]* remap 0x0000e0 page 92 cs[3]* & boot cs* remap 0x0000e8 page 92 GT-96100A advanced communication controller 480 revision 1.0 cpu address decode (continued) pci_0 i/o remap 0x0000f0 page 92 pci_0 memory 0 remap 0x0000f8 page 92 pci_0 memory 1 remap 0x000100 page 93 pci_1 i/o remap 0x000108 page 93 pci_1 memory 0 remap 0x000110 page 93 pci_1 memory 1 remap 0x000118 page 93 cpu errors report cpu error address (low) 0x070 page 151 cpu error address (high) 0x078 page 151 cpu error data (low) 0x128 page 151 cpu error data (high) 0x130 page 151 cpu error parity 0x138 page 151 cpu sync barrier pci_0 sync barrier virtual register 0x0000c0 page 94 pci_1 sync barrier virtual register 0x0000c8 page 94 table 437: sdram registers map description offset page number sdram and device address decode scs[0]* low decode address 0x000400 page 130 scs[0]* high decode address 0x000404 page 130 scs[1]* low decode address 0x000408 page 130 scs[1]* high decode address 0x00040c page 130 scs[2]* low decode address 0x000410 page 131 scs[2]* high decode address 0x000414 page 131 scs[3]* low decode address 0x000418 page 131 scs[3]* high decode address 0x00041c page 131 cs[0]* low decode address 0x000420 page 131 cs[0]* high decode address 0x000424 page 132 table 436: cpu registers map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 481 sdram and device address decode (continued) cs[1]* low decode address 0x000428 page 132 cs[1]* high decode address 0x00042c page 132 cs[2]* low decode address 0x000430 page 132 cs[2]* high decode address 0x000434 page 132 cs[3]* low decode address 0x000438 page 133 cs[3]* high decode address 0x00043c page 133 boot cs* low decode address 0x000440 page 133 boot cs* high decode address 0x000444 page 133 address decode error 0x000470 page 133 sdram configuration sdram configuration 0x000448 page 134 sdram operation mode 0x000474 page 135 sdram burst mode 0x000478 page 135 sdram address decode 0x00047c page 136 sdram parameters sdram bank0 parameters 0x00044c page 137 sdram bank1 parameters 0x000450 page 138 sdram bank2 parameters 0x000454 page 138 sdram bank3 parameters 0x000458 page 139 ecc ecc upper data 0x000480 page 139 ecc lower data 0x000484 page 139 ecc from memory 0x000488 page 139 ecc calculated 0x00048c page 139 ecc error report 0x000490 page 140 table 437: sdram registers map (continued) description offset page number GT-96100A advanced communication controller 482 revision 1.0 device parameters device bank0 parameters 0x00045c page 140 device bank1 parameters 0x000460 page 141 device bank2 parameters 0x000464 page 141 device bank3 parameters 0x000468 page 141 device boot bank parameters 0x00046c page 142 table 438: dma registers map description offset page number dma record channel 0 dma byte count 0x000800 page 232 channel 1 dma byte count 0x000804 page 232 channel 2 dma byte count 0x000808 page 232 channel 3 dma byte count 0x00080c page 233 channel 0 dma source address 0x000810 page 233 channel 1 dma source address 0x000814 page 233 channel 2 dma source address 0x000818 page 233 channel 3 dma source address 0x00081c page 233 channel 0 dma destination address 0x000820 page 233 channel 1 dma destination address 0x000824 page 234 channel 2 dma destination address 0x000828 page 234 channel 3 dma destination address 0x00082c page 234 channel 0 next record pointer 0x000830 page 234 channel 1 next record pointer 0x000834 page 234 channel 2 next record pointer 0x000838 page 235 channel 3 next record pointer 0x00083c page 235 channel 0 current descriptor pointer 0x000870 page 235 channel 1 current descriptor pointer 0x000874 page 235 channel 2 current descriptor pointer 0x000878 page 235 channel 3 current descriptor pointer 0x00087c page 236 table 437: sdram registers map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 483 dma record (continued) channel 0 control 0x000840 page 236 channel 1 control 0x000844 page 239 channel 2 control 0x000848 page 239 channel 3 control 0x00084c page 239 dma arbiter arbiter control 0x000860 page 240 table 439: timer/counter registers map description offset page number timer /counter 0 0x000850 page 403 timer /counter 1 0x000854 page 403 timer /counter 2 0x000858 page 403 timer /counter 3 0x00085c page 404 timer /counter control 0x000864 page 404 table 440: pci registers map description offset page number pci internal pci_0 command 0x000c00 page 172 pci_1 command 0x000c80 page 174 pci_0 time out & retry 0x000c04 page 174 pci_1 time out & retry 0x000c84 page 174 pci_0 scs[1:0]* bank size 0x000c08 page 175 pci_1 scs[1:0]* bank size 0x000c88 page 175 pci_0 scs[3:2]* bank size 0x000c0c page 175 pci_1 scs[3:2]* bank size 0x000c8c page 176 pci_0 cs[2:0]* bank size 0x000c10 page 176 pci_1 cs[2:0]* bank size 0x000c90 page 176 table 438: dma registers map (continued) description offset page number GT-96100A advanced communication controller 484 revision 1.0 pci internal (continued) pci_0 cs[3]* & boot cs* bank size 0x000c14 page 177 pci_1 cs[3]* & boot cs* bank size 0x000c94 page 177 pci_0 base address registers? enable 0x000c3c page 178 pci_1 base address registers? enable 0x000cbc page 179 pci_0 prefetch/max burst size 0x000c40 page 179 pci_1 prefetch/max burst size 0x000cc0 page 179 pci_0 scs[1:0]* base address remap 0x000c48 page 180 pci_1 scs[1:0]* base address remap 0x000cc8 page 180 pci_0 scs[3:2]* base address remap 0x000c4c page 181 pci_1 scs[3:2]* base address remap 0x000ccc page 179 pci_0 cs[2:0]* base address remap 0x000c50 page 182 pci_1 cs[2:0]* base address remap 0x000cd0 page 182 pci_0 cs[3]* & boot cs* address remap 0x000c54 page 182 pci_1 cs[3]* & boot cs* address remap 0x000cd4 page 182 pci_0 swapped scs[1:0]* base address remap 0x000c58 page 180 pci_1 swapped scs[1:0]* base address remap 0x000cd8 page 180 pci_0 swapped scs[3:2]* base address remap 0x000c5c page 181 pci_1 swapped scs[3:2]* base address remap 0x000cdc page 181 pci_0 swapped cs[3]* & bootcs* base address remap 0x000c64 page 183 pci_1 swapped cs[3]* & bootcs* base address remap 0x000ce4 page 183 pci_0 configuration address 0x000cf8 page 183 pci_1 configuration address 0x000cf0 page 184 pci_0 configuration data virtual register 0x000cfc page 184 pci_1 configuration data virtual register 0x000cf4 page 184 pci_0 interrupt acknowledge virtual register 0x000c34 page 184 pci_1 interrupt acknowledge virtual register 0x000c30 page 184 table 440: pci registers map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 485 pci configuration pci_0 device and vendor id 0x000000 page 185 pci_1 device and vendor id 0x000080 page 185 pci_0 status and command 0x000004 page 186 pci_1 status and command 0x000084 page 187 pci_0 class code and revision id 0x000008 page 188 pci_1 class code and revision id 0x000088 page 188 pci_0 bist, header type, latency timer, cache line 0x00000c page 188 pci_1 bist, header type, latency timer, cache line 0x00008c page 189 pci_0 scs[1:0]* base address 0x000010 page 190 pci_1 scs[1:0]* base address 0x000090 page 190 pci_0 scs[3:2]* base address 0x000014 page 191 pci_1 scs[3:2]* base address 0x000094 page 191 pci_0 cs[2:0]* base address 0x000018 page 191 pci_1 cs[2:0]* base address 0x000098 page 192 pci_0 cs[3]* & boot cs* base address 0x00001c page 192 pci_1 cs[3]* & boot cs* base address 0x00009c page 192 pci_0 internal registers memory mapped base address 0x000020 page 193 pci_1 internal registers memory mapped base address 0x0000a0 page 193 pci_0 internal registers i/o mapped base address 0x000024 page 193 pci_1 internal registers i/o mapped base address 0x0000a4 page 193 pci_0 subsystem id and subsystem vendor id 0x00002c page 194 pci_1 subsystem id and subsystem vendor id 0x0000ac page 194 expansion rom base address register 0x000030 page 194 pci_0 interrupt pin and line 0x00003c page 195 pci_1 interrupt pin and line 0x0000bc page 195 table 440: pci registers map (continued) description offset page number GT-96100A advanced communication controller 486 revision 1.0 pci configuration, function 1 pci_0 swapped scs[1:0]* base address 0x000110 page 198 pci_1 swapped scs[1:0]* base address 0x000190 page 198 pci_0 swapped scs[3:2]* base address 0x000114 page 198 pci_1 swapped scs[3:2]* base address 0x000194 page 199 pci_0 swapped cs[3]* & boot cs* base address 0x00011c page 199 pci_1 swapped cs[3]* & boot cs* base address 0x00019c page 200 table 441: interrupts registers map description offset page number interrupt main cause register 0x000c18 page 428 interrupt0* main mask register 0x000c1c page 432 interrupt1* main mask register 0x000c24 page 434 interrupt high cause register 0x000c98 page 430 interrupt0* high mask register 0x000c9c page 433 interrupt1* high mask register 0x000ca4 page 435 interrupt0* select register 0x000c70 page 431 interrupt1* select register 0x000c74 page 432 serial cause register 0x103a00 page 436 serint0* mask register 0x103a80 page 438 serint1* mask register 0x103a88 page 439 ethernet0 cause register 0x084850 page 440 ethernet0 mask register 0x084858 page 440 ethernet1 cause register 0x088850 page 441 ethernet1 mask register 0x088858 page 441 sdma cause register 0x103a10 page 441 sdma mask register 0x103a90 page 441 mpsc0 cause register 0x103a20 page 444 mpsc0 mask register 0x103aa0 page 444 mpsc1 cause register 0x103a24 page 445 table 440: pci registers map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 487 mpsc1 mask register 0x103aa4 page 445 mpsc2 cause register 0x103a28 page 445 mpsc2 mask register 0x103aa8 page 445 mpsc3 cause register 0x103a2c page 446 mpsc3 mask register 0x103aac page 446 mpsc4 cause register 0x103a30 page 446 mpsc4 mask register 0x103ab0 page 446 mpsc5 cause register 0x103a34 page 446 mpsc5 mask register 0x103ab4 page 446 mpsc6 cause register 0x103a38 page 446 mpsc6 mask register 0x103ab8 page 446 mpsc7 cause register 0x103a3c page 446 mpsc7 mask register 0x103abc page 446 flextdm cause register 0x103a40 page 447 flextdm mask register 0x103ac0 page 447 brg cause register 0x103a48 page 448 brg mask register 0x103ac8 page 448 gpp0 cause register 0x103a50 page 448 gpp0 mask register 0x103ad0 page 448 gpp1 cause register 0x103a54 page 449 gpp1 mask register 0x103ad4 page 449 gpp2 cause register 0x103a58 page 449 gpp2 mask register 0x103ad8 page 449 pci_0 serr0 mask 0x000c28 page 449 pci_1 serr1 mask 0x000ca8 page 451 table 441: interrupts registers map (continued) description offset page number GT-96100A advanced communication controller 488 revision 1.0 note: i 2 o registers can be accessed from the cpu and pci_0 sides (unless stated otherwise). if accessed from the pci_0 side, address offset is with respect to the pci_0 scs[1:0]* base address register contents. if accessed from cpu side, the address offset is with respect to the cpu internal space base register + 0x1c00. table 442: i 2 o support registers map description offset page number inbound message register 0 0x00010 page 211 inbound message register 1 0x00014 page 211 outbound message register 0 0x00018 page 211 outbound message register 1 0x0001c page 211 inbound doorbell register 0x00020 page 212 inbound interrupt cause register 0x00024 page 212 inbound interrupt mask register 0x00028 page 213 outbound doorbell register 0x0002c page 213 outbound interrupt cause register 0x00030 page 214 outbound interrupt mask register 0x00034 page 214 inbound queue port virtual register 0x00040 page 215 outbound queue port virtual register 0x00044 page 215 queue control register 0x00050 page 215 queue base address register 0x00054 page 216 inbound free head pointer register 0x00060 page 216 inbound free tail pointer register 0x00064 page 216 inbound post head pointer register 0x00068 page 216 inbound post tail pointer register 0x0006c page 217 outbound free head pointer register 0x00070 page 217 outbound free tail pointer register 0x00074 page 217 outbound post head pointer register 0x00078 page 218 outbound post tail pointer register 0x0007c page 218 GT-96100A advanced communication controller revision 1.0 489 table 443: communication unit register map description offset page number ethernet ports ethernet phy address register (epar) 0x080800 page 285 ethernet smi register (esmir) 0x080810 page 286 ethernet0 ports ethernet0 port configuration register (e0pcr) 0x084800 page 286 ethernet0 port configuration extend register (e0pcxr) 0x084808 page 288 ethernet0 port command register (e0pcmr) 0x084810 page 291 ethernet0 port status register (e0psr) 0x084818 page 291 ethernet0 serial parameters register (e0spr) 0x084820 page 292 ethernet0 hash table pointer register (e0htpr) 0x084828 page 293 ethernet0 flow control source address low (e0fcsal) 0x084830 page 293 ethernet0 flow control source address high (e0fcsah) 0x084838 page 294 ethernet0 sdma configuration register (e0sdcr) 0x084840 page 294 ethernet0 sdma command register (e0sdcmr) 0x084848 page 295 ethernet0 interrupt cause register (e0icr) 0x084850 page 296 ethernet0 interrupt mask register (e0imr) 0x084858 page 299 ethernet0 ip differentiated services codepoint to priority0 low (e0dscp2p0l) 0x84860 page 299 ethernet0 ip differentiated services codepoint to priority0 high (e0dscp2p0h) 0x84864 page 299 ethernet0 ip differentiated services codepoint to priority1 low (e0dscp2p1l) 0x84868 page 299 ethernet0 ip differentiated services codepoint to priority1 high (e0dscp2p1h) 0x8486c page 299 ethernet0 vlan priority tag to priority (e0vpt2p) 0x88870 page 299 ethernet0 first rx descriptor pointer 0 (e0frdp0) 0x084880 page 263 ethernet0 first rx descriptor pointer 1 (e0frdp1) 0x084884 ethernet0 first rx descriptor pointer 2 (e0frdp2) 0x084888 ethernet0 first rx descriptor pointer 3 (e0frdp3) 0x08488c ethernet0 current rx descriptor pointer 0 (e0crdp0) 0x0848a0 ethernet0 current rx descriptor pointer 1 (e0crdp1) 0x0848a4 ethernet0 current rx descriptor pointer 2 (e0crdp2) 0x0848a8 ethernet0 current rx descriptor pointer 3 (e0crdp3) 0x0848ac GT-96100A advanced communication controller 490 revision 1.0 ethernet0 ports (continued) ethernet0 current tx descriptor pointer 0 (e0ctdp0) 0x0848e0 page 255 ethernet0 current tx descriptor pointer 1 (e0ctdp1) 0x0848e4 ethernet0 mib counters 0x085800 - 0x0858ff page 302 ethernet1 ports ethernet1 port configuration register (e1pcr) 0x088800 page 286 ethernet1 port configuration extend register (e1pcxr) 0x088808 page 288 ethernet1 port command register (e1pcmr) 0x088810 page 291 ethernet1 port status register (e1psr) 0x088818 page 291 ethernet1 serial parameters register (e1spr) 0x088820 page 292 ethernet1 hash table pointer register (e1htpr) 0x088828 page 293 ethernet1 flow control source address low (e1fcsal) 0x088830 page 293 ethernet1 flow control source address high (e1fcsah) 0x088838 page 294 ethernet1 sdma configuration register (e1sdcr) 0x088840 page 294 ethernet1 sdma command register (e1sdcmr) 0x088848 page 295 ethernet1 interrupt cause register (e0icr) 0x088850 page 296 ethernet1 interrupt mask register (e0imr) 0x088858 page 299 ethernet ip differentiated services codepoint to priority0 low (e0dscp2p0l) 0x84860 page 299 ethernet ip differentiated services codepoint to priority0 high (e0dscp2p0h) 0x84864 page 299 ethernet ip differentiated services codepoint to priority1 low (e0dscp2p1l) 0x84868 page 299 ethernet ip differentiated services codepoint to priority1 high (e0dscp2p1h) 0x8486c page 299 ethernet vlan priority tag to priority (e0vpt2p) 0x84870 page 299 ethernet1 first rx descriptor pointer 0 (e1frdp0) 0x088880 page 263 ethernet1 first rx descriptor pointer 1 (e1frdp1) 0x088884 ethernet1 first rx descriptor pointer 2 (e1frdp2) 0x088888 ethernet1 first rx descriptor pointer 3 (e1frdp3) 0x08888c table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 491 ethernet1 current rx descriptor pointer 0 (e1crdp0) 0x0888a0 page 263 ethernet1 current rx descriptor pointer 1 (e1crdp1) 0x0888a4 ethernet1 current rx descriptor pointer 2 (e1crdp2) 0x0888a8 ethernet1 current rx descriptor pointer 3 (e1crdp3) 0x0888ac ethernet1 current tx descriptor pointer 0 (e1ctdp0) 0x0888e0 page 255 ethernet1 current tx descriptor pointer 1 (e1ctdp1) 0x0888e4 ethernet1 mib counters 0x089800 - 0x0898ff page 302 sdmas sdma group configuration register 0x101af0 page 312 sdma group 0, channel0 channel0 configuration register (s0dc0) 0x000 9 00 page 312 channel0 command register (s0dcm0) 0x000 9 08 page 314 channel0 rx descriptor 0x008 9 00 - 0x008 9 0f not to be accessed during nor- mal opera- tion. channel0 current rx descriptor pointer (s0crdp0) 0x008 9 10 page 316 channel0 tx descriptor 0x00c 9 00 - 0x00c 9 0f not to be accessed during nor- mal opera- tion. channel0 current tx descriptor pointer (s0ctdp0) 0x00c 9 10 page 316 channel0 first tx descriptor pointer (s0ftdp0) 0x00c 9 14 page 316 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 492 revision 1.0 sdma group 0, channel1 channel1 configuration register (s0dc1) 0x010 9 00 for a description of the channel1 registers, see the descrip- tions for the channel0 registers. channel1 command register (s0dcm1) 0x010 9 08 channel1 rx descriptor 0x018 9 00 - 0x018 9 0f channel1 current rx descriptor pointer (s0crdp1) 0x018 9 10 channel1 tx descriptor 0x01c 9 00 - 0x01c 9 0f channel1 current tx descriptor pointer (s0ctdp1) 0x01c 9 10 channel1 first tx descriptor pointer (s0ftdp1) 0x01c 9 14 sdma group 0, channel2 channel2 configuration register (s0dc2) 0x020 9 00 for a description of the channel2 registers, see the descrip- tions for the channel0 registers. channel2 command register (s0dcm2) 0x020 9 08 channel2 rx descriptor 0x028 9 00 - 0x028 9 0f channel2 current rx descriptor pointer (s0crdp2) 0x028 9 10 channel2 tx descriptor 0x02c 9 00 - 0x02c 9 0f channel2 current tx descriptor pointer (s0ctdp2) 0x02c 9 10 channel2 first tx descriptor pointer (s0ftdp2) 0x02c 9 14 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 493 sdma group 0, channel3 channel3 configuration register (s0dc3) 0x030 9 00 for a description of the channel3 registers, see the descrip- tions for the channel0 registers. channel3 command register (s0dcm3) 0x030 9 08 channel3 rx descriptor 0x038 9 00 - 0x038 9 0f channel3 current rx descriptor pointer (s0crdp3) 0x038 9 10 channel3 tx descriptor 0x03c 9 00 - 0x03c 9 0f channel3 current tx descriptor pointer (s0ctdp3) 0x03c 9 10 channel3 first tx descriptor pointer (s0ftdp3) 0x03c 9 14 sdma group 0, channel4 channel4 configuration register (s0dc4) 0x040 9 00 for a description of the channel4 registers, see the descrip- tions for the channel0 registers. channel4 command register (s0dcm4) 0x040 9 08 channel4 rx descriptor 0x048 9 00 - 0x048 9 0f channel4 current rx descriptor pointer (s0crdp4) 0x048 9 10 channel4 tx descriptor 0x04c 9 00 - 0x04c 9 0f channel4 current tx descriptor pointer (s0ctdp4) 0x04c 9 10 for a description of the channel4 registers, see the descrip- tions for the channel0 registers. channel4 first tx descriptor pointer (s0ftdp4) 0x04c 9 14 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 494 revision 1.0 sdma group 0, channel5 channel5 configuration register (s0dc5) 0x050 9 00 for a description of the channel5 registers, see the descrip- tions for the channel0 registers. channel5 command register (s0dcm5) 0x050 9 08 channel5 rx descriptor 0x058 9 00 - 0x058 9 0f channel5 current rx descriptor pointer (s0crdp5) 0x058 9 10 channel5 tx descriptor 0x05c 9 00 - 0x05c 9 0f channel5 current tx descriptor pointer (s0ctdp5) 0x05c 9 10 channel5 first tx descriptor pointer (s0ftdp5) 0x05c 9 14 sdma group 0, channel6 channel6 configuration register (s0dc6) 0x060 9 00 for a description of the channel6 registers, see the descrip- tions for the channel0 registers. channel6 command register (s0dcm6) 0x060 9 08 channel6 rx descriptor 0x068 9 00 - 0x068 9 0f channel6 current rx descriptor pointer (s0crdp6) 0x068 9 10 channel6 tx descriptor 0x06c 9 00 - 0x06c 9 0f channel6 current tx descriptor pointer (s0ctdp6) 0x06c 9 10 channel6 first tx descriptor pointer (s0ftdp6) 0x06c 9 14 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 495 sdma group 0, channel7 channel7 configuration register (s0dc7) 0x070 9 00 for a description of the channel7 registers, see the descrip- tions for the channel0 registers. channel7 command register (s0dcm7) 0x070 9 08 channel7 rx descriptor 0x078 9 00 - 0x078 9 0f channel7 current rx descriptor pointer (s0crdp7) 0x078 9 10 channel7 tx descriptor 0x07c 9 00 - 0x07c 9 0f channel7 current tx descriptor pointer (s0ctdp7) 0x07c 9 10 channel7 first tx descriptor pointer (s0ftdp7) 0x07c 9 14 sdma group 1, channel0 channel1 configuration register (s1dc0) 0x100 9 00 page 312 channel1 command register (s1dcm0) 0x100 9 08 page 314 channel1 rx descriptor 0x108 9 00 - 0x108 9 0f not to be accessed during nor- mal opera- tion. channel1 current rx descriptor pointer (s1crdp0) 0x108 9 10 page 316 channel1 tx descriptor 0x10c 9 00 - 0x10c 9 0f not to be accessed during nor- mal opera- tion. channel1 current tx descriptor pointer (s1ctdp0) 0x10c 9 10 page 316 channel1 first tx descriptor pointer (s1ftdp0) 0x10c 9 14 page 316 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 496 revision 1.0 sdma group 1, channel1 channel1 configuration register (s1dc1) 0x110 9 00 for a description of the channel1 registers, see the descrip- tions for the channel0 registers. channel1 command register (s1dcm1) 0x110 9 08 channel1 rx descriptor 0x118 9 00 - 0x118 9 0f channel1 current rx descriptor pointer (s1crdp1) 0x118 9 10 channel1 tx descriptor 0x11c 9 00 - 0x11c 9 0f sdma group 1, channel1 (continued) channel1 current tx descriptor pointer (s1ctdp1) 0x11c 9 10 for a description of the channel1 registers, see the descrip- tions for the channel0 registers. channel1 first tx descriptor pointer (s1ftdp1) 0x11c 9 14 sdma group 1, channel2 channel2 configuration register (s1dc2) 0x120 9 00 for a description of the channel2 registers, see the descrip- tions for the channel0 registers. channel2 command register (s1dcm2) 0x120 9 08 channel2 rx descriptor 0x128 9 00 - 0x128 9 0f channel2 current rx descriptor pointer (s1crdp2) 0x128 9 10 channel2 tx descriptor 0x12c 9 00 - 0x12c 9 0f channel2 current tx descriptor pointer (s1ctdp2) 0x12c 9 10 channel2 first tx descriptor pointer (s1ftdp2) 0x12c 9 14 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 497 sdma group 1, channel3 channel3 configuration register (s1dc3) 0x130 9 00 for a description of the channel3 registers, see the descrip- tions for the channel0 registers. channel3 command register (s1dcm3) 0x130 9 08 channel3 rx descriptor 0x138 9 00 - 0x138 9 0f channel3 current rx descriptor pointer (s1crdp3) 0x138 9 10 channel3 tx descriptor 0x13c 9 00 - 0x13c 9 0f channel3 current tx descriptor pointer (s1ctdp3) 0x13c 9 10 channel3 first tx descriptor pointer (s1ftdp3) 0x13c 9 14 sdma group 1, channel4 channel4 configuration register (s1dc4) 0x140 9 00 for a description of the channel4 registers, see the descrip- tions for the channel0 registers. channel4 command register (s1dcm4) 0x140 9 08 channel4 rx descriptor 0x148 9 00 - 0x148 9 0f channel4 current rx descriptor pointer (s1crdp4) 0x148 9 10 channel4 tx descriptor 0x14c 9 00 - 0x14c 9 0f channel4 current tx descriptor pointer (s1ctdp4) 0x14c 9 10 channel4 first tx descriptor pointer (s1ftdp4) 0x14c 9 14 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 498 revision 1.0 sdma group 1, channel5 channel5 configuration register (s1dc5) 0x150 9 00 for a description of the channel5 registers, see the descrip- tions for the channel0 registers. channel5 command register (s1dcm5) 0x150 9 08 channel5 rx descriptor 0x158 9 00 - 0x158 9 0f channel5 current rx descriptor pointer (s1crdp5) 0x158 9 10 channel5 tx descriptor 0x15c 9 00 - 0x15c 9 0f channel5 current tx descriptor pointer (s1ctdp5) 0x15c 9 10 channel5 first tx descriptor pointer (s1ftdp5) 0x15c 9 14 sdma group 1, channel6 channel6 configuration register (s1dc6) 0x160 9 00 for a description of the channel6 registers, see the descrip- tions for the channel0 registers. channel6 command register (s1dcm6) 0x160 9 08 channel6 rx descriptor 0x168 9 00 - 0x168 9 0f channel6 current rx descriptor pointer (s1crdp6) 0x168 9 10 channel6 tx descriptor 0x16c 9 00 - 0x16c 9 0f channel6 current tx descriptor pointer (s1ctdp6) 0x16c 9 10 for a description of the channel6 registers, see the descrip- tions for the channel0 registers. channel6 first tx descriptor pointer (s1ftdp6) 0x16c 9 14 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 499 sdma group 1, channel7 channel7 configuration register (s1dc7) 0x170 9 00 for a description of the channel7 registers, see the descrip- tions for the channel0 registers. channel7 command register (s1dcm7) 0x170 9 08 channel7 rx descriptor 0x178 9 00 - 0x178 9 0f channel7 current rx descriptor pointer (s1crdp7) 0x178 9 10 channel7 tx descriptor 0x17c 9 00 - 0x17c 9 0f channel7 current tx descriptor pointer (s1ctdp7) 0x17c 9 10 channel7 first tx descriptor pointer (s1ftdp7) 0x17c 9 14 mpsc0 mpsc0 main configuration low (mmcrl0) 0x000 a 00 page 329 mpsc0 main configuration high (mmcrh0) 0x000 a 04 page 333 mpsc0 protocol configuration (mpcr0) 0x000 a 08 page 339 channel0 register1 (ch0r1) 0x000 a 0c page 337 channel0 register2 (ch0r2) 0x000 a 10 channel0 register3 (ch0r3) 0x000 a 14 channel0 register4 (ch0r4) 0x000 a 18 channel0 register5 (ch0r5) 0x000 a 1c channel0 register6 (ch0r6) 0x000 a 20 channel0 register7 (ch0r7) 0x000 a 24 channel0 register8 (ch0r8) 0x000 a 28 channel0 register9 (ch0r9) 0x000 a 2c channel0 register10 (ch0r10) 0x000 a 30 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 500 revision 1.0 mpsc1 mpsc1 main configuration low (mmcrl1) 0x008 a 00 for a description of the mpsc1 registers, see the descrip- tions for the mpsc0 registers on page 499 . mpsc1 main configuration high (mmcrh1) 0x008 a 04 mpsc1 protocol configuration (mpcr1) 0x008 a 08 channel1 register1 (ch1r1) 0x008 a 0c channel1 register2 (ch1r2) 0x008 a 10 channel1 register3 (ch1r3) 0x008 a 14 channel1 register4 (ch1r4) 0x008 a 18 channel1 register5 (ch1r5) 0x008 a 1c channel1 register6 (ch1r6) 0x008 a 20 channel1 register7 (ch1r7) 0x008 a 24 channel1 register8 (ch1r8) 0x008 a 28 channel1 register9 (ch1r9) 0x008 a 2c channel1 register10 (ch1r10) 0x008 a 30 channel1 register11 (ch1r11) 0x008 a 34 mpsc2 mpsc2 main configuration low (mmcrl2) 0x010 a 00 for a description of the mpsc1 registers, see the descrip- tions for the mpsc0 registers on page 499 . mpsc2 main configuration high (mmcrh2) 0x010 a 04 mpsc2 protocol configuration (mpcr2) 0x010 a 08 channel2 register1 (ch2r1) 0x010 a 0c channel2 register2 (ch2r2) 0x010 a 10 channel2 register3 (ch2r3) 0x010 a 14 channel2 register4 (ch2r4) 0x010 a 18 channel2 register5 (ch2r5) 0x010 a 1c channel2 register6 (ch2r6) 0x010 a 20 channel2 register7 (ch2r7) 0x010 a 24 channel2 register8 (ch2r8) 0x010 a 28 channel2 register9 (ch2r9) 0x010 a 2c channel2 register10 (ch2r10) 0x010 a 30 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 501 mpsc3 mpsc3 main configuration low (mmcrl3) 0x018 a 00 for a description of the mpsc3 registers, see the descrip- tions for the mpsc0 registers on page 499 . mpsc3 main configuration high (mmcrh3) 0x018 a 04 mpsc3 protocol configuration (mpcr3) 0x018 a 08 channel3 register1 (ch3r1) 0x018 a 0c channel3 register2 (ch3r2) 0x018 a 10 channel3 register3 (ch3r3) 0x018 a 14 channel3 register4 (ch3r4) 0x018 a 18 channel3 register5 (ch3r5) 0x018 a 1c channel3 register6 (ch3r6) 0x018 a 20 channel3 register7 (ch3r7) 0x018 a 24 channel3 register8 (ch3r8) 0x018 a 28 channel3 register9 (ch3r9) 0x018 a 2c channel3 register10 (ch3r10) 0x018 a 30 mpsc4 mpsc4 main configuration low (mmcrl4) 0x020 a 00 for a description of the mpsc4 registers, see the descrip- tions for the mpsc0 registers on page 499 . mpsc4 main configuration high (mmcrh4) 0x020 a 04 mpsc4 protocol configuration (mpcr4) 0x020 a 08 channel4 register1 (ch4r1) 0x020 a 0c channel4 register2 (ch4r2) 0x020 a 10 channel4 register3 (ch4r3) 0x020 a 14 channel4 register4 (ch4r4) 0x020 a 18 channel4 register5 (ch4r5) 0x020 a 1c channel4 register6 (ch4r6) 0x020 a 20 channel4 register7 (ch4r7) 0x020 a 24 channel4 register8 (ch4r8) 0x020 a 28 channel4 register9 (ch4r9) 0x020 a 2c channel4 register10 (ch4r10) 0x020 a 30 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 502 revision 1.0 mpsc5 mpsc5 main configuration low (mmcrl5) 0x028 a 00 for a description of the mpsc5 registers, see the descrip- tions for the mpsc0 registers on page 499 . mpsc5 main configuration high (mmcrh5) 0x028 a 04 mpsc5 protocol configuration (mpcr5) 0x028 a 08 channel5 register1 (ch5r1) 0x028 a 0c channel5 register2 (ch5r2) 0x028 a 10 channel5 register3 (ch5r3) 0x028 a 14 channel5 register4 (ch5r4) 0x028 a 18 channel5 register5 (ch5r5) 0x028 a 1c channel5 register6 (ch5r6) 0x028 a 20 channel5 register7 (ch5r7) 0x028 a 24 channel5 register8 (ch5r8) 0x028 a 28 channel5 register9 (ch5r9) 0x028 a 2c channel5 register10 (ch5r10) 0x028 a 30 mpsc6 mpsc6 main configuration low (mmcrl6) 0x030 a 00 for a description of the mpsc6 registers, see the descrip- tions for the mpsc0 registers on page 499 . mpsc6 main configuration high (mmcrh6) 0x030 a 04 mpsc6 protocol configuration (mpcr6) 0x030 a 08 channel6 register1 (ch6r1) 0x030 a 0c channel6 register2 (ch6r2) 0x030 a 10 channel6 register3 (ch6r3) 0x030 a 14 channel6 register4 (ch6r4) 0x030 a 18 channel6 register5 (ch6r5) 0x030 a 1c channel6 register6 (ch6r6) 0x030 a 20 channel6 register7 (ch6r7) 0x030 a 24 channel6 register8 (ch6r8) 0x030 a 28 channel6 register9 (ch6r9) 0x030 a 2c channel6 register10 (ch6r10) 0x030 a 30 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 503 mpsc7 mpsc7 main configuration low (mmcrl7) 0x038 a 00 for a description of the mpsc7 registers, see the descrip- tions for the mpsc0 registers on page 499 . mpsc7 main configuration high (mmcrh7) 0x038 a 04 mpsc7 protocol configuration (mpcr7) 0x038 a 08 channel7 register1 (ch7r1) 0x038 a 0c channel7 register2 (ch7r2) 0x038 a 10 channel7 register3 (ch7r3) 0x038 a 14 channel7 register4 (ch7r4) 0x038 a 18 channel7 register5 (ch7r5) 0x038 a 1c channel7 register6 (ch7r6) 0x038 a 20 channel7 register7 (ch7r7) 0x038 a 24 channel7 register8 (ch7r8) 0x038 a 28 channel7 register9 (ch7r9) 0x038 a 2c channel7 register10 (ch7r10) 0x038 a 30 flextdm0 flextdm0 transmit dual port ram (tdpr0), block 0 0x000 b 00 - 0x000 b ff flextdm0 transmit dual port ram (tdpr0), block 1 0x001 b 00 - 0x001 b ff flextdm0 transmit dual port ram (tdpr0), block 2 0x002 b 00 - 0x002 b ff flextdm0 transmit dual port ram (tdpr0), block 3 0x003 b 00 - 0x003 b ff flextdm0 receive dual port ram (rdpr0), block 0 0x004 b 00 - 0x004 b ff flextdm0 receive dual port ram (rdpr0), block 1 0x005 b 00 - 0x005 b ff flextdm0 receive dual port ram (rdpr0), block 2 0x006 b 00 - 0x006 b ff flextdm0 receive dual port ram (rdpr0), block 3 0x007 b 00 - 0x007 b ff flextdm0 transmit read pointer (ttrp0) 0x008 b 00 flextdm0 receive read pointer (trrp0) 0x008 b 04 flextdm0 configuration register (tcr0) 0x008 b 08 page 384 flextdm0 aux channela tx register (ata0) 0x008 b 0c flextdm0 aux channela rx register (ara0) 0x008 b 10 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 504 revision 1.0 flextdm0 (continued) flextdm0 aux channelb tx register (atb0) 0x008 b 14 flextdm0 aux channelb rx register (arb0) 0x008 b 18 flextdm1 flextdm1 transmit dual port ram (tdpr1), block 0 0x010 b 00 - 0x010 b ff flextdm1 transmit dual port ram (tdpr1), block 1 0x011 b 00 - 0x011 b ff flextdm1 transmit dual port ram (tdpr1), block 2 0x012 b 00 - 0x012 b ff flextdm1 transmit dual port ram (tdpr1), block 3 0x013 b 00 - 0x013 b ff flextdm1 receive dual port ram (rdpr1), block 0 0x014 b 00 - 0x014 b ff flextdm1 receive dual port ram (rdpr1), block 1 0x015 b 00 - 0x015 b ff flextdm1 receive dual port ram (rdpr1), block 2 0x016 b 00 - 0x016 b ff flextdm1 receive dual port ram (rdpr1), block 3 0x017 b 00 - 0x017 b ff flextdm1 transmit read pointer (ttrp1) 0x018 b 00 flextdm1 receive read pointer (trrp1) 0x018 b 04 flextdm1 configuration register (tcr1) 0x018 b 08 page 384 flextdm1 aux channela tx register (ata1) 0x018 b 0c flextdm1 aux channela rx register (ara1) 0x018 b 10 flextdm1 aux channelb tx register (atb1) 0x018 b 14 flextdm1 aux channelb rx register (arb1) 0x018 b 18 flextdm2 flextdm2 transmit dual port ram (tdpr2), block 0 0x020 b 00 - 0x020 b ff flextdm2 transmit dual port ram (tdpr2), block 1 0x021 b 00 - 0x021 b ff flextdm2 transmit dual port ram (tdpr2), block 2 0x022 b 00 - 0x022 b ff flextdm2 transmit dual port ram (tdpr2), block 3 0x023 b 00 - 0x023 b ff flextdm2 receive dual port ram (rdpr2), block 0 0x024 b 00 - 0x024 b ff flextdm2 receive dual port ram (rdpr2), block 1 0x025 b 00 - 0x025 b ff flextdm2 receive dual port ram (rdpr2), block 2 0x026 b 00 - 0x026 b ff flextdm2 receive dual port ram (rdpr2), block 3 0x027 b 00 - 0x027 b ff flextdm2 transmit read pointer (ttrp2) 0x028 b 00 flextdm2 receive read pointer (trrp2) 0x028 b 04 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 505 flextdm2 (continued) flextdm2 configuration register (tcr2) 0x028 b 08 page 384 flextdm2 aux channela tx register (ata2) 0x028 b 0c flextdm2 aux channela rx register (ara2) 0x028 b 10 flextdm2 aux channelb tx register (atb2) 0x028 b 14 flextdm2 aux channelb rx register (arb2) 0x028 b 18 flextdm3 flextdm3 transmit dual port ram (tdpr3), block 0 0x030 b 00 - 0x030 b ff flextdm3 transmit dual port ram (tdpr3), block 1 0x031 b 00 - 0x031 b ff flextdm3 transmit dual port ram (tdpr3), block 2 0x032 b 00 - 0x032 b ff flextdm3 transmit dual port ram (tdpr3), block 3 0x033 b 00 - 0x033 b ff flextdm3 receive dual port ram (rdpr3), block 0 0x034 b 00 - 0x034 b ff flextdm3 receive dual port ram (rdpr3), block 1 0x035 b 00 - 0x035 b ff flextdm3 receive dual port ram (rdpr3), block 2 0x036 b 00 - 0x036 b ff flextdm3 receive dual port ram (rdpr3), block 3 0x037 b 00 - 0x037 b ff flextdm3 transmit read pointer (ttrp3) 0x038 b 00 flextdm3 receive read pointer (trrp3) 0x038 b 04 flextdm3 configuration register (tcr3) 0x038 b 08 page 384 flextdm3 aux channela tx register (ata3) 0x038 b 0c flextdm3 aux channela rx register (ara3) 0x038 b 10 flextdm3 aux channelb tx register (atb3) 0x038 b 14 flextdm3 aux channelb rx register (arb3) 0x038 b 18 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 506 revision 1.0 baud rate generators brg0 configuration register (bcr0) 0x102 a 00 page 399 brg0 baud tuning register (btr0) 0x102 a 04 page 400 brg1 configuration register (bcr1) 0x102 a 08 for brg1 through brg7 con- figuration and tuning registers, see brg0 brg1 baud tuning register (btr1) 0x102 a 0c brg2 configuration register (bcr2) 0x102 a 10 brg2 baud tuning register (btr2) 0x102 a 14 brg3 configuration register (bcr3) 0x102 a 18 brg3 baud tuning register (btr3) 0x102 a 1c brg4 configuration register (bcr4) 0x102 a 20 brg4 baud tuning register (btr4) 0x102 a 24 brg5 configuration register (bcr5) 0x102 a 28 brg5 baud tuning register (btr5) 0x102 a 2c brg6 configuration register (bcr6) 0x102 a 30 brg6 baud tuning register (btr6) 0x102 a 34 brg7 configuration register (bcr7) 0x102 a 38 brg7 baud tuning register (btr7) 0x102 a 3c routing registers main routing register (mrr) 0x101 a 00 page 414 receive clock routing register (rcrr) 0x101 a 10 page 418 transmit clock routing register (tcrr) 0x101 a 20 page 420 general purpose ports general purpose configuration 0 (gpc0) 0x100 a 00 page 407 general purpose configuration 1 (gpc1) 0x100 a 04 page 409 general purpose configuration 2 (gpc2) 0x100 a 08 page 412 general purpose input/output 0 (gpio0) 0x100 a 20 page 407 general purpose input/output 1 (gpio1) 0x100 a 24 page 410 general purpose input/output 2 (gpio2) 0x100 a 28 page 412 general purpose data 0 (gpd0) 0x100 a 40 page 408 general purpose data 1 (gpd1) 0x100 a 44 page 410 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller revision 1.0 507 general purpose ports (continued) general purpose data 2 (gpd2) 0x100 a 48 page 413 general purpose level 0 (gpl0) 0x100 a 60 page 408 general purpose level 1 (gpl1) 0x100 a 64 page 411 general purpose level 2 (gpl2) 0x100 a 68 page 413 watchdog watchdog configuration register (wdc) 0x101 a 80 page 401 watchdog value register (wdv) 0x101 a 84 page 402 communication unit arbiter comm unit arbiter configuration register (cuacr) 0x101 a c0 page 251 pci arbiters pci_0 arbiter configuration register 0x101 a e0 page 243 pci_1 arbiter configuration register 0x101 a e4 page 245 table 443: communication unit register map (continued) description offset page number GT-96100A advanced communication controller 508 revision 1.0 31. dc c haracteristics note: operation at or beyond the maximum ratings is not recommended or guaranteed. extended exposure at the maximum rating for extended periods of time may adversely affect device reliability. table 444: absolute maximum ratings symbol parameter min. max. unit v cc 2.5 core supply voltage -0.3 3.0 v v cc 3.3 io supply voltage -0.3 4.0 v v i input voltage -0.3 5.5 v i ik input protect diode current +-20 ma i ok output protect diode current +-20 ma t c operating case temperature 0 110 c t stg storage temperature -40 125 c table 445: recommended operating conditions symbol parameter min. typ. max. unit v cc 2.5 core supply voltage 2.375 2.5 2.625 v v cc 3.3 i/o supply voltage 3.15 3.3 3.45 v v i input voltage -0.3 5.5 v v o output voltage 0 v cc 3.3 v t c case temperature 0 70 c table 446: pin capacitance symbol parameter min. typ. max. unit c in input capacitance pci pad 2.5 4.5 pf input capacitance non pci pad 2 3.5 c out output capacitance pci pad 2.5 4.5 pf output capacitance non pci pad 2 3.5 GT-96100A advanced communication controller revision 1.0 509 31.1 dc electrical characteristics over operating range (tc=0-70 o c; v cc 3.3=+3.3v, +/-5%, v cc 2.5= +2.5v, +/-5%) table 447: dc electrical characteristics over operating range symbol parameter test condition min. max. unit loading vih input high level guaranteed logic high level 2.0v v vil input low level guaranteed logic low level 0.8v v voh output high volt- age: ioh = 8,12,16,24 1 ma 1. see table 448, ?driving pad characteristics,? on page 510. 2.4 v 50pf vol output low volt- age: iol = 8,12,16,24 1 ma 0.4 v 50pf iih input high current +-1 ua iil input low current +-1 ua iozh high impedance output current +-1 ua iozl high impedance output current +-1 ua icc operating current i/o vcc3.3=3.465v f = 100mhz tclk/ 66mhz pclk 440 ma core vcc2.5=2.625v f = 100mhz tclk/ 66mhz pclk 880 ma GT-96100A advanced communication controller 510 revision 1.0 31.1.1 power sequencing notes the voltage power must be turned on sequentially so that the highest voltage power is always the preceding one; i.e.the highest voltage power must be turned on first, then the second highest voltage power and so on and so forth. this power up sequence must be used due to the presence of protection diodes between the two power rails. if the power is turned on in incorrect sequence and if the tie-high terminal becomes tie low, these diodes leaks current. likewise, when powering down, turn off the lowest voltage first. turn off the next highest and so on and so forth. table 448: driving pad characteristics output current pads name pci pads cbe0_[3:0], cbe1_[3:0], devsel0_, devsel1_, frame0_, frame1_, gnt0_, gnt1_, idsel0, idsel1, interrupt1_, irdy0_, irdy1_, lock0_, pad0[31:0], pad1[31:0], par0, par1, pclk0, pclk1, perr0_, perr1_, req0_, req1_, serr0_, serr1_, stop0_, stop1_, trdy0_, trdy1_, reset_ 4ma pads jtag[3] 8ma pads gpp[15:0], mdc, mdio, mii0[14:0], mii1[14:0], nmi_, porta[6:0], portb[6:0], portc[6:0], portd[6:0], porte[6:0], portf[6:0], wde_ 16ma pads ad[63:0], adp[1], adp[3:2], adp[7:6], ale, bypsoe_, clkoutpll, cstiming_, dmareq_[0], interrupt0_, scdoe_, scs_[3:0], scword[1:0], sdqm[7:0], serint0_, serint1_, sysad[63:0], sysadc[7;0], syscmd[8:0], validin_, wrrdy_ 24ma pads adp[0], adp[5:4], banksel, dadr[10:0], dmareq_[3:1], dwr_, scas_, sras_ GT-96100A advanced communication controller revision 1.0 511 31.1.2 power consumption figure 83 illustrate the GT-96100A power consumption in various common configurations and frequencies. figure 83: power vs. operating frequency GT-96100A power (0.25um) vs. operating freq. @ 64 bit pci, 4 tdms and 4 idmas active, 8 mpscs in 2mbit/s fdx, 2 fdx fastethernet 0.00 1.00 2.00 3.00 4.00 operating freq. GT-96100A power power 1.29 1.83 1.99 2.35 1.34 1.87 2.04 2.40 1.27 1.80 1.97 2.33 pcore 0.73 1.06 1.16 1.38 0.74 1.06 1.17 1.39 0.77 1.09 1.20 1.42 tclk 50 75 83 100 50 75 83 100 50 75 83 100 pciclk 25 25 25 25 33 33 33 33 66 66 66 66 1 2 3 4 5 6 7 8 9 10 11 12 GT-96100A power (0.25um) vs. operating freq. @ 64 bit pci, 4 tdms and 4 idmas active, 4 mpscs in 55mbit/s fdx, 4 mpscs in 2mbit/s fdx, 2 fdx fastethernet 0.00 1.00 2.00 3.00 4.00 operating freq. GT-96100A power power 1.40 1.94 2.10 2.47 1.45 1.99 2.15 2.51 1.38 1.92 2.08 2.44 pcore 0.77 1.10 1.20 1.43 0.78 1.11 1.21 1.43 0.81 1.14 1.24 1.46 tclk 50 75 83 100 50 75 83 100 50 75 83 100 pciclk 25 25 25 25 33 33 33 33 66 66 66 66 123456789101112 GT-96100A advanced communication controller 512 revision 1.0 31.2 thermal data table 449 shows the package thermal data for the GT-96100A. using the commercial grade device, galileo technology recommends the use of heatsink for most systems, espe- cially those with little or no airflow. use an adequate airflow, layout, and other means to meet the recommended operating conditions listed in table 449 . table 449: thermal data for GT-96100A in bga 492 airflow 0 m/s 1 m/s 2 m/s j a 1 8 .5 c / w 16 . 6 c / w 1 5 c / w j t 0 . 3 7 c/w 0. 43 c / w 0.53 c / w j c 5. 9 c/w GT-96100A advanced communication controller revision 1.0 513 32. ac t iming note: the following targets are subject to change. table 450: ac timing measurement formulas commercial industrial i/o supply voltage : tcase= 70o c; vcc= +3.3v, +/- 5% core supply voltage : tcase= 70o c; vcc= +2.5v, +/- 5% note: ac timing specifications for the 66mhz industrial grade part will be included in future revisions of this datasheet. table 451: ac commercial grade timing all delays, setup, and hold times are referred to tclk rising edge, unless stated otherwise. signals description 83 mhz 100 mhz unit loading min. max. min. max. clk tclk pulse width high 4.8 4 ns tclk pulse width low 4.8 4 ns tclk clock period 12 10 ns tclk rise time tbd tbd v/ns tclk fall time tbd tbd v/ns reset** active device reset 10 10 tclk cycle cpu interface sysad[63:0], syscmd[8:0], valid- out*, release*, sctce* setup 3.5 2.5 ns scmatch setup 5 2.5 sysad[63:0], syscmd[8:0], valid- out*, release*, sctce*, scmatch hold 1 1 ns GT-96100A advanced communication controller 514 revision 1.0 cpu interface (continued) sysad[63:0], syscmd[8:0], sysadc[7:0], scdoe*, validin*, wrrdy*, scword[1:0], interrupt0* output delay2725ns50pf pci interface pclk0, pclk1 clock period 15 15 ns all bussed inputs setup 4 3.5 ns all point to point inputs setup 7 6 all inputs hold 0 0 ns all outputs, except req* output delay2928ns req* output delay 2 11 2 10 ns memory interface ad[63:0] setup 3 2 ns ad[63:0] hold 1 1 ns ad[63:0], scs[3:0]*output delay2725.5ns50pf dadr[10:0] output delay2725ns50pf dadr[2:0] output delay (device burst) 2725ns50pf dadr[10:3] output delay from tclk fall- ing (device write) 2726ns50pf adp[7:0] output delay (parity) 2725.5ns50pf adp[7:0] setup (parity) 3 2 ns 50pf adp[7:0] hold (parity) 1 1 ns adp[3:0]/eot[3:0]* setup (eot[3:0]*) 43ns table 451: ac commercial grade timing (continued) all delays, setup, and hold times are referred to tclk rising edge, unless stated otherwise. signals description 83 mhz 100 mhz unit loading min. max. min. max. GT-96100A advanced communication controller revision 1.0 515 memory interface (continued) adp[3:0]/eot[3:0]* hold (eot[3:0]*) 11ns adp[1]/ale output delay (ale) 2 7 2 5.5 ns 30pf adp[1]/ale output delay, tclk falling (ale) 2726ns30pf adp[3]/dwr* output delay (dwr*) 2726ns50pf adp[5:4]/{dadr[11], banksel[1]} output delay (dadr[11], banksel[1]) 2726ns50pf adp[7:6]/ {sras*,scas*} output delay (sras* and scas*) 2726ns50pf sdqm[7:0] output delay 2 7 2 6 ready* setup 6 5 ns ready* hold 1 1 ns dmareq[0]*/mreq*/ sras* setup (dmareq[0]/ mreq*) 4.5 3.5 ns dmareq[0]*/mreq*/ sras* hold (dmareq[0]/ mreq*) 11ns dmareq[0]*/mreq*/ sras* output delay (sras*) 2726ns50pf dmareq[1]*/ banksel[1] setup (dmareq[1]*) 4.5 3.5 ns dmareq[1]*/ banksel[1] hold (dmareq[1]*) 11ns dmareq[1]*/ banksel[1] output delay (banksel[1]) 2725ns50pf dmareq[2]*/dadr[11] setup (dmareq[2]*) 4.5 3.5 ns table 451: ac commercial grade timing (continued) all delays, setup, and hold times are referred to tclk rising edge, unless stated otherwise. signals description 83 mhz 100 mhz unit loading min. max. min. max. GT-96100A advanced communication controller 516 revision 1.0 32.1 tclk/pclk restrictions tclk cycle must be smaller than pclk cycle by at least 1ns (t pclk> t tclk + 1ns). this restriction applies to all sync modes. there is one exception to this restriction. tclk and pclk can run at the same frequency if the following condi- tions are met: ? the two clocks are synchronized (derived from the same clock source). ? if running at sync mode 1, a minimum skew of 5.5ns must be observed between rising edge of tclk and pclk, as shown in figure 84 . galileo technology recommends using an inverted tclk as pclk in order to guarantee this skew. ? if running at sync mode 2 or 3, a maximum skew of 2ns between rising edge of tclk and pclk must be met. memory interface (continued) dmareq[2]*/dadr[11] hold (dmareq[2]*) 11ns dmareq[2]*/dadr[11] output delay (dadr[11]) 1.3 7 1.3 5 ns 50pf dmareq[3]*/scas*/ eot[0]* setup (dmareq[3]*/ eot[0]*) 4.5 3.5 ns dmareq[3]*/scas*/ eot[0]* hold (dmareq[3]*/ eot[0]*) 11ns dmareq[3]*/scas*/ eot[0]* output delay (scas*) 27.526ns50pf mgnt*/bypsoe* output delay (mgnt*) 2726ns30pf mgnt*/bypsoe* output delay (bypass oe*) 2 7.5 2 6.5 ns 30pf sras*,scas*, dwr*output delay2725ns50pf ale output delay2725.5ns30pf ale output delay, tclk falling 2725.5ns30pf cstiming* output delay2725.5ns30pf table 451: ac commercial grade timing (continued) all delays, setup, and hold times are referred to tclk rising edge, unless stated otherwise. signals description 83 mhz 100 mhz unit loading min. max. min. max. GT-96100A advanced communication controller revision 1.0 517 figure 84: tclk = pclk, in sync mode = 1, skew requirement in addition to the above restriction, there are few sync modes specific restrictions, summarized in table 452 . the sync mode can be programed by the cpu, the pci or during autoload. for sync mode information, see sec- tion 7.14.1 ?pci internal registers? on page 172 . table 452: tclk/pclk restrictions sync mode pclk frequency range restrictions 0,4 from dc up to tclk t pclk > t tclk + 1ns 1 from tclk/2 up to tclk t pclk < 2t tclk -1ns, unless running with synchronized t pclk = 2t tclk and minimum skew of 5.5ns between pclk rise and tclk rise is guaranteed, as shown in figure 84 . for exam- ple, if t tclk = 15ns (66mhz), t pclk should be smaller than 29ns (unless running with synchronized clocks). note: to guarantee this skew, galileo technology recom- mends using an inverted tclk as pclk. 2,3 from tclk/2 up to tclk tclk and pclk are synchronized , and a maximum skew of 2ns between pclk rise and tclk rise is guaranteed. 5 from tclk/3 up to tclk/2 t pclk < 3t tclk - 1ns, unless running with synchronized t pclk = 3t tclk and minimum skew of 5.5ns between pclk rise and tclk rise is guaranteed. for example, if t tclk = 13.3ns (75mhz), t pclk should be smaller than 39ns (unless running with synchronized clocks). 6,7 from tclk/3 up to tclk/2 tclk and pclk are synchronized , and a maximum skew of 2ns between pclk rise and tclk rise is guaranteed. tclk pclk tclk to pclk 5.5ns minimum skew pclk to tclk 5.5ns minimum skew GT-96100A advanced communication controller 518 revision 1.0 32.2 serial (communication) clock domain ac characteristic (tc= 0 - 70c; vddi/o= +3.3v, +/- 5%; vddc = +2.5v=/-5%; external load=50pf) note: for information on the settings for receive sync delay (rsd), transmit sync delay(tsd), driving edge (de), and sync edge (se), see section 15.4 ?flextdm configuration register (tcr)? on page 384 . figure 85: flex-tdm receive timing - normal clock waveform table 453: flex-tdm receive timing - normal clock symbol description min max unit t20 trclk cycle time 18 ns t21 trclk width low 7.2 ns t22 trclk width high 7.2 ns t23 trsync setup time 5 ns t24 trsync hold time 5 ns t25 trsync rise and fall time 15 ns t27 trxd setup time 5 ns t28 trxd hold time 5 ns t20 t21 t20 t21 t22 t22 t25 t23 t25 t24 t27 t28 rsd=1 bit0 trclk (se=0, de=0) trclk (se=1, de=1) trsync trxd GT-96100A advanced communication controller revision 1.0 519 figure 86: flex-tdm transmit timing - normal speed clock waveform table 454: flex-tdm transmit timing - normal speed clock symbol description min max unit t40 ttclk cycle time 18 ns t41 ttclk width low 7.2 ns t42 ttclk width high 7.2 ns t43 ttsync setup time 5 ns t44 ttsync hold time 5 ns t45 ttsync rise and fall time 15 ns t46 tdstrb output delay 13 ns t47 ttclk to tdclk delay time 8 ns t48 ttxd output delay 13 ns t40 t40 t41 t42 t41 t42 t45 t43 t45 t44 t47 t48 t46 tsd=0 bit0 ttclk (se=0, de=0) ttclk (se=1, de=1) ttsync ttxd tdstrb toclk (se=0, de=0) toclk (se=1, de=1) GT-96100A advanced communication controller 520 revision 1.0 figure 87: flex-tdm receive timing - double speed clock waveform table 455: flex-tdm receive timing - double speed clock symbol description min max unit t30 trclk cycle time 18 ns t31 trclk width low 7.2 ns t32 trclk width high 7.2 ns t33 trsync setup time 5 ns t34 trsync hold time 5 ns t35 trsync rise and fall time 15 ns t37 trxd setup time 5 ns t38 trxd hold time 5 ns t30 t31 t30 t31 t32 t32 t35 t33 t35 t34 t37 t38 rsd=1 bit0 trclk (se=0, ce=0) trclk (se=1, de=1) trsync trxd toclk (se=0, de=0) toclk (se=1, de=1) GT-96100A advanced communication controller revision 1.0 521 figure 88: flex-tdm receive timing - double speed clock waveform table 456: flex-tdm transmit timing - double speed clock symbol description min max unit t50 ttclk cycle time 18 ns t51 ttclk width low 7.2 ns t52 ttclk width high 7.2 ns t53 ttsync setup time 5 ns t54 ttsync hold time 5 ns t55 ttsync rise and fall time 15 ns t56 tdstrb output delay 13 ns t57 ttclk to tdclk delay 8 ns t58 ttxd output delay 13 ns t30 t31 t30 t31 t32 t32 t35 t33 t35 t34 t37 t38 rsd=0 bit0 bit1 trclk (se=0, de=1) trclk (se=1, de=0) trsync trxd toclk (se=1, de=0) toclk (se=0, de=1) GT-96100A advanced communication controller 522 revision 1.0 figure 89: flex-tdm transmit timing - double speed clock waveform figure 90: flex-tdm transmit timing - double speed clock waveform t50 t51 t52 t t t55 t53 t t54 t57 t58 t56 bit0 ttclk (se=0, ce=0) ttclk (se=1, de=1) ttsync ttxd tdstrb toclk (se=0, de=0) toclk (se=1, de=1) tsd=0 t50 t t51 t52 t t55 t53 t t54 t57 t58 t56 tsd=1 bit0 ttclk (se=0, de=1) ttclk (se=1, de=0) ttsync ttxd tdstrb toclk (se=0, de=1) toclk (se=1, de=0) GT-96100A advanced communication controller revision 1.0 523 figure 91: mpsc receive timing table 457: mpsc receive timing symbol description min max unit t60 rclk cycle time 18 ns t61 rclk width low 7.2 ns t62 rclk width high 7.2 ns t63 rxd setup time 5 ns t64 rxd hold time 5 ns t65 cd* setup time 5 ns t66 cd* hold time 5 ns t60 t61 t62 t63 t64 t65 t66 rclk rxd cd* GT-96100A advanced communication controller 524 revision 1.0 figure 92: mpsc transmit timing table 458: mpsc transmit timing symbol description min max unit t70 tclk cycle time 18 ns t71 tclk width low 7.2 ns t72 tclk width high 7.2 ns t73 txd delay time 13 ns t74 rts* delay time 13 ns t75 cts* setup time 5 ns t76 cts* hold time 5 ns t70 t71 t72 t76 t75 t73 t74 tclk txd rts* cts* GT-96100A advanced communication controller revision 1.0 525 32.3 mpsc waveforms 32.3.1 output delay from rts* figure 93: output delay from rts*, asynchronous cts* (ctss=0 in mmcrlx) waveform figure 94: output delay from rts*, synchronous cts* (ctss=1 in mmcrlx) waveform first bit last bit tclk txd rts* cts* first bit last bit tclk txd rts* cts* GT-96100A advanced communication controller 526 revision 1.0 32.3.2 output delay from cts* figure 95: output delay from cts*, asynchronous cts* (ctss=0 in mmcrlx) waveform figure 96: output delay from cts*, synchronous cts* (ctss=1 in mmcrlx) waveform 32.3.3 cts* loss in synchronous protocol figure 97: cts* loss in synchronous protocol: start of frame waveform with cts lost first bit last bit tclk txd rts* cts* first bit last bit tclk txd rts* cts* cts* loss first bit, rts* forced high tclk txd rts* cts* GT-96100A advanced communication controller revision 1.0 527 figure 98: cts* loss in synchronous protocol: start of frame waveform without cts lost figure 99: cts* loss in synchronous protocol, synchronous cts* (ctss=1 in mmcrlx) waveform figure 100:cts* loss in synchronous protocol, asynchronous cts* (ctss=0 in mmcrlx) waveform 32.3.4 reception control using cd* figure 101:reception control using cd* waveform no cts* lost tclk txd rts* cts* first bit rts* forced high cts* lost tclk txd rts* cts* first bit rts* forced high cts* loss tclk txd rts* cts* first bit last bit rclk rxd cd* GT-96100A advanced communication controller 528 revision 1.0 32.3.5 external sync figure 102:external sync (rsyl=0 in mmcrhx), cd* pulse mode (cdm=0 in mmcrlx) waveform 32.3.6 transmit synchronize to receive figure 103:transmit synchronize to receive (tsyn=1 in mmcrlx), external sync (rsyl=0 in mmcrhx) waveform figure 104:transmit synchronize to receive (tsyn=1 in mmcrlx), external sync (rsyl=0 in mmcrhx), cd* and cts* pulse mode (ctsm=1 and cdm=1 in mmcrlx), synchronous cts* (ctss=1 in mmcrlx) waveform note: cd* and cts* are connected to the same signal. first bit last bit due to enter hunt no effect pulse mode first bit next frame rclk rxd cd* bit0 bit1 bit2 bit3 bit4 bit5 bit6 bit7 bit0 bit0 rclk tclk rxd cd* txd rts* cts* bit0 bit1 bit2 bit3 bit4 bit5 bit6 bit7 bit0 bit0 rclk tclk rxd cd*/cts* txd rts* GT-96100A advanced communication controller revision 1.0 529 32.4 mii waveforms 32.4.1 transmit timing figure 105:mii port transmit signals timing 32.4.2 receive timing table 459: mii transmit timing symbol description min typ max unit tmtxcc mii txclk cycle 40t 1 1. t=1 for 100mb/s operation, t=10 for 10mb/s operation ns tmtxch mii txclk high 15t 25t ns tmtxcl mii txclk low 15t 25t ns tmtxv mii txclk rising to txd, txen valid 20 ns tmtxh mii txd, txen hold after txclk rising 5 ns table 460: mii receive timing symbol description min typ max unit tmrxcc mii rxclk cycle 40t 1 1. t=1 for 100mb/s operation, t=10 for 10mb/s operation ns tmrxch mii rxclk high 15t 25t ns tmrxcl mii rxclk low 15t 25t ns tmrxs mii rxd, rxdv setup before rxclk rising 10 ns tmrxh mii rxd, rxdv hold after rxclk rising 5 ns 0ns min 20ns max txclk txd, txen vih min vil max vih min vil max GT-96100A advanced communication controller 530 revision 1.0 figure 106:mii port receive signals timing 32.5 jtag ac characteristics figure 107:jtag ac timing table 461: jtag ac characteristics symbol description min max unit tjck jtack clock period 1000 ns tjckh tck high period 400 ns tjckl tck low period 400 ns tjdis tdi and tms setup time 20 ns tjdih tdi and tms hold time 20 ns tjdo tdo output delay 2 20 ns 10ns min rxclk rxd, rxdv, rxer 10ns min vih min vil max vih min vil max tjdo tjck tjkl tjckh tjdih tjdis tck tdi, tms tdo GT-96100A advanced communication controller revision 1.0 531 32.6 additional delay due to capacitive loading some applications may require additional capacitive loading on different output pins of the GT-96100A. for example, when using multiple GT-96100A devices connected to the same sysad bus, the 50pf load specifica- tion may be exceeded. this additional loading affects the output delays of the signals, depending on the drive strength of the output driver. the following section describes how to calculate the affects of additional loading on the output drivers. 32.6.1 calculating the maximum delay due to loading the basic equation for calculating the maximum delay is: tmax = [atypa + (btyp * cr)] * 1.6 where: ? tmax is the maximum delay in nanoseconds. ? atypa must be calculated by the designer as shown in section 32.6.1.1 ?calculating atypa? on page 531 . ? btyp is a parameter according to the specific output buffer from table 462 . ? cr is the capacitance required, in picofarads. 32.6.1.1 calculating atypa atypa can be calculated by using the given values in the ac timing parameters table. we start with the equation: tspec = [atypa + (btyp * cds)] * 1.6 and solving for atypa: atypa = (tspec/1.6) - (btyp * cds) where: ? tspec is the maximum delay parameter from the ac timing parameters table, in nanoseconds. ? btyp is a parameter according to the specific output buffer from table 462 . ? cds is the capacitance parameter from the ac timing parameters table, in picofarads. note: 1.6 is the worst case derating factor. 32.6.2 calculating the minimum delay due to loading the basic equation for calculating the maximum delay is: tmin = [atypb + (btyp * cr)] * 0.7 where: ? tmin is the minimum delay in nanoseconds ? atypb must be calculated by the designer as shown in section 32.6.2.1 ?calculating atypb? on page 532 ? btyp is a parameter according to the specific output buffer from table 462 ? cr is the capacitance required, in picofarads. GT-96100A advanced communication controller 532 revision 1.0 32.6.2.1 calculating atypb atypb can be calculated by using the given values in the ac timing parameters table. we start with the equation: tspec = [atypb + (btyp * cds)] * 0.7 and solving for atypb: atypb = (tspec/0.7) - (btyp * cds) where: ? tspec is the maximum delay parameter from the ac timing parameters table, in nanoseconds ? btyp is a parameter according to the specific output buffer from table 462 ? cds is the capacitance parameter from the ac timing parameters table, in picofarads. note: 0.7 is the worst case derating factor. 32.6.3 btyp values table 462 lists the btyp values for the different output buffers of the GT-96100A. see the dc parameters section for the corresponding pin and output driver. 32.6.4 tmax calculating example the following is an example of how to calculate the maximum delay on the ad[0] line for a 75pf load. from the ac timing parameters table, for a 50pf load, the maximum output delay on the ad[0] line is speci- fied as 7ns for 83 mhz. looking at table 462 , btyp for ad[0], which is an 8ma driver, is = 0.031 (low to high transition). substituting these values into: atypa = (tspec/1.6) - (btyp * cds) gives atypa = 2.83. substituting atypa of 3.45, btyp of 0.031 and cr of 75pf in: tmax = [atypa + (btyp * cr)] * 1.6 gives tmax = 8.25. this means that the maximum output delay of ad[0] with a 75pf load is 8.25ns. table 462: btyp values output driver low to high btyp value high to low btype value 4ma 0.06 0.077 8ma 0.031 0.039 12ma 0.021 0.028 16ma 0.018 0.022 all pci outputs 0.015 0.018 GT-96100A advanced communication controller revision 1.0 533 33. p inout t able , 492 p in bga note: the following table is sorted by ball number. table 463: GT-96100A pinout table ball # signal name a01?a26 b01?b26 c01?c26 a01 req0_ b01 pad0[28] c01 pad0[24] a02 gpp[14] b02 jtag[3] c02 pad0[30] a03 gpp[13] b03 jtag[0] c03 gnt0_ a04 gpp[6] b4 vsspll c04 jtag[1] a05 vccpll b05 gpp[7] c05 gpp[12] a06 mii1[14] b06 gpp[2] c06 gpp[9] a07 mii1[10] b07 mdc c07 gpp[3] a08 mii1[4] b08 mii1[13] c08 gpp[0] a09 mii1[3] b09 mii1[9] c09 mii1[12] a10 nc b10 mii1[5] c10 mii1[6] a11 mii0[12] b11 mii1[1] c11 mii1[8] a12 mii0[11] b12 mii0[13] c12 nc a13 mii0[8] b13 mii0[9] c13 mii0[6] a14 mii0[2] b14 mii0[5] c14 mii0[4] a15 mii0[1] b15 nc c15 portf[5] a16 portf[6] b16 portf[3] c16 portf[1] a17 portf[4] b17 porte[6] c17 porte[3] a18 portf[2] b18 porte[4] c18 portd[6] a19 porte[5] b19 portd[5] c19 nc a20 porte[1] b20 portd[0] c20 portc[5] a21 portd[4] b21 portc[6] c21 portc[1] a22 nc b22 portc[0] c22 portb[4] a23 portc[3] b23 portb[0] c23 porta[3] a24 portb[1] b24 porta[2] c24 dmareq[0]_ a25 porta[4] b25 ready_ c25 ad[0] a26 porta[0] b26 ad[33] c26 ad[2] GT-96100A advanced communication controller 534 revision 1.0 d01?d26 e01?e26 f01?10, f17?f26 d01 pad0[17] e01 irdy0_ f01 perr0_ d02 pad0[25] e02 pad0[20] f02 frame0_ d03 pad0[29] e03 pad0[23] f03 pad0[18] d04 jtag[2] e04 pad0[26] f04 pad0[22] d05 jtag[4] e05 pad0[31] f05 pad0[27] d06 gpp[8] e06 gpp[15] f06 gnd d07 gpp[5] e07 gpp[10] f07 gnd d08 gpp[1] e08 gpp[11] f08 vcc 2.5 d09 mdio e09 gpp[4] f09 vcc 3.3 d10 mii1[11] e10 nc f10 vcc 3.3 d11 mii1[2] e11 mii1[7] f17 vcc 3.3 d12 mii0[14] e12 mii1[0] f18 vcc 2.5 d13 mii0[7] e13 mii0[10] f19 vcc 2.5 d14 mii0[0] e14 mii0[3] f20 gnd d15 portf[0] e15 nc f21 gnd d16 porte[2] e16 portd[2] f22 ad[1] d17 porte[0] e17 portd[3] f23 ad[36] d18 portd[1] e18 portc[2] f24 ad[4] d19 portc[4] e19 portb[2] f25 ad[39] d20 portb[6] e20 portb[3] f26 ad[11] d21 portb[5] e21 porta[5] g01?g06 d22 porta[6] e22 porta[1] g01 pad0[14] d23 ale e23 bypsoe_ g02 devsel0_ d24 cstiming_ e24 ad[34] g03 cbe0_[2] d25 ad[32] e25 ad[5] g04 pad0[21] d26 ad[37] e26 ad[9] g05 idsel0 g06 gnd table 463: GT-96100A pinout table (continued) ball # signal name GT-96100A advanced communication controller revision 1.0 535 g21?g26 j21?j26 l11?l16, l22?l26 g21 gnd j21 vcc 3.3 l11 gnd g22 ad[35] j22 ad[38] l12 gnd g23 ad[6] j23 ad[10] l13 gnd g24 ad[7] j24 ad[12] l14 gnd g25 ad[42] j25 ad[45] l15 gnd g26 ad[13] j26 adp[4] l16 gnd h01?h06, h21?h26 k01?k06, k21?k26 l22 ad[46] h01 pad0[10] k01 pad0[6] l23 adp[1] h02 par0 k02 pad0[9] l24 ad[15] h03 trdy0_ k03 pad0[13] l25 adp[5] h04 pad0[16] k04 cbe0_[1] l26 sdqm[5] h05 cbe0_[3] k05 lock0_ m01?m05, m11?m16, m22?m26 h06 vcc 2.5 k06 vcc 3.3 m01 pad0[1] h21 vcc 2.5 k21 vcc 3.3 m02 pad0[2] h22 ad[3] k22 ad[41] m03 pad0[5] h23 ad[8] k23 ad[44] m04 cbe0_[0] h24 ad[40] k24 ad[14] m05 pad0[3] h25 ad[43] k25 ad[47] m11 gnd h26 adp[0] k26 sdqm[0] m12 gnd j01?j06 j01?j05 m13 gnd j01 pad0[8] l01 pad0[4] m14 gnd j02 pad0[12] l02 pad0[7] m15 gnd j03 pad0[15] l03 vref0 m16 gnd j04 stop0_ l04 pad0[11] m22 dwr_ j05 pad0[19] l05 serr0_ m23 sdqm[4] j06 vcc 2.5 m24 scas_ m25 sdqm[1] m26 scs_[0] table 463: GT-96100A pinout table (continued) ball # signal name GT-96100A advanced communication controller 536 revision 1.0 n01?n05, n11?n16, n22?n26 p22?p26 t11?t16, t22?t26 n01 pad0[0] p22 dadr[4] t11 gnd n02 tclk p23 dadr[7] t12 gnd n03 nc p24 dadr[3] t13 gnd n04 pclk0 p25 dadr[2] t14 gnd n05 nc p26 dadr[5] t15 gnd n11 gnd r01?r05, r11?r16, r22?r26 t16 gnd n12 gnd r01 pad1[30] t22 ad[17] n13 gnd r02 pad1[25] t23 sdqm[7] n14 gnd r03 cbe1_[3] t24 dmareq_[1] n15 gnd r04 pad1[24] t25 nc n16 gnd r05 pad1[27] t26 dadr[10] n22 scs_[1] r11 gnd u01?u06, u21?u26 n23 dadr[0] r12 gnd u01 pad1[26] n24 dadr[1] r13 gnd u02 pad1[22] n25 sras_ r14 gnd u03 pad1[23] n26 nc r15 gnd u04 pad1[19] p01?p05, p11?p16 r16 gnd u05 perr1_ p01 pad1[28] r22 dadr[9] u06 vcc 3.3 p02 pclk1 r23 scs_[2] u21 vcc 3.3 p03 clkoutpll r24 dmareq_[2] u22 ad[48] p04 nc r25 dadr[8] u23 adp[6] p05 pad1[29] r26 dadr[6] u24 sdqm[3] p11 gnd t01?t05 u25 scs_[3] p12 gnd t01 pad1[31] u26 dmareq_[3] p13 gnd t02 vref1 p14 gnd t03 pad1[17] p15 gnd t04 idsel1 p16 gnd t05 pad1[16] table 463: GT-96100A pinout table (continued) ball # signal name GT-96100A advanced communication controller revision 1.0 537 v01?v06, v21?v26 y01?y06, y21?y26 aa23?aa26 v01 pad1[20] y01 cbe1_[2] aa23 ad[55] v02 pad1[18] y02 devsel1_ aa24 ad[22] v03 frame1_ y03 pad1[13] aa25 ad[51] v04 stop1_ y04 pad1[14] aa26 ad[16] v05 pad1[15] y05 pad1[4] ab01?ab24 v06 vcc 3.3 y06 gnd ab01 serr1_ v21 vcc 2.5 y21 gnd ab02 pad1[9] v22 ad[53] y22 ad[56] ab03 pad1[5] v23 ad[49] y23 ad[23] ab04 sysad[4] v24 adp[3] y24 ad[20] ab05 sysad[46] v25 sdqm[6] y25 ad[18] ab06 sysad[45] v26 banksel[0] y26 adp[2] ab07 sysad[12] w01?w06, w21?w26 aa01?aa10, aa17?aa22 ab08 sysad[33] w01 pad1[21] aa01 trdy1_ ab09 sysadc[1] w02 irdy1_ aa02 pad1[12] ab10 nc w03 par1 aa03 pad1[11] ab11 sysad[62] w04 cbe1_[1] aa04 pad1[10] ab12 sysad[52] w05 cbe1_[0] aa05 pad1[0] ab13 nc w06 vcc 2.5 aa06 gnd ab14 nc w21 vcc 2.5 aa07 gnd ab15 sysad[20] w22 ad[25] aa08 vcc 2.5 ab16 sysad[26] w23 ad[52] aa09 vcc 2.5 ab17 syscmd[1] w24 ad[50] aa10 vcc 3.3 ab18 scdoe_ w25 adp[7] aa17 vcc 3.3 ab19 interrupt1_ w26 sdqm[2] aa18 vcc 3.3 ab20 interrupt0_ aa19 vcc 2.5 ab21 bypasspll aa20 gnd ab22 ad[29] aa21 gnd ab23 ad[58] aa22 ad[27] ab24 ad[24] table 463: GT-96100A pinout table (continued) ball # signal name GT-96100A advanced communication controller 538 revision 1.0 ab25?ab26 ad01?ad26 ae01?ae26 ab25 ad[54] ad01 pad1[6] ae01 pad1[7] ab26 ad[19] ad02 pad1[2] ae02 req1_ ac01?ac26 ad03 sysad[40] ae03 sysad[10] ac01 pad1[8] ad04 sysad[37] ae04 sysad[13] ac02 pad1[1] ad05 sysad[41] ae05 sysad[11] ac03 pad1[3] ad06 sysad[15] ae06 sysad[9] ac04 gnt1_ ad07 sysad[38] ae07 sysad[35] ac05 sysad[8] ad08 sysad[34] ae08 sysad[3] ac06 sysad[39] ad09 sysad[0] ae09 sysad[1] ac07 sysad[14] ad10 sysadc[3] ae10 sysadc[0] ac08 sysad[44] ad11 sysadc[6] ae11 sysadc[2] ac09 sysadc[5] ad12 sysad[49] ae12 sysad[30] ac10 sysadc[7] ad13 sysad[16] ae13 sysad[29] ac11 sysad[63] ad14 sysad[17] ae14 sysad[28] ac12 sysad[51] ad15 sysad[24] ae15 sysad[25] ac13 sysad[19] ad16 sysad[22] ae16 sysad[21] ac14 sysad[18] ad17 sysad[23] ae17 sysad[53] ac15 sysad[50] ad18 syscmd[6] ae18 sysad[56] ac16 sysad[57] ad19 validout_ ae19 syscmd[5] ac17 syscmd[7] ad20 release_ ae20 syscmd[3] ac18 syscmd[2] ad21 nc ae21 wrrdy_ ac19 validin_ ad22 serint0_ ae22 scword[1] ac20 scmatch ad23 nmi_ ae23 reset_ ac21 scword[0] ad24 ad[30] ae24 wde_ ac22 ad[62] ad25 ad[60] ae25 ad[31] ac23 ad[63] ad26 ad[57] ae26 ad[59] ac24 ad[28] ac25 ad[26] ac26 ad[21] table 463: GT-96100A pinout table (continued) ball # signal name GT-96100A advanced communication controller revision 1.0 539 note: all nc pins must be connected to ground for future devices compatibility. in order to use these pins in a future device, galileo technology recommends that these pins be connected by zero ohm resistors. af01?af26 af01 sysad[36] af02 sysad[7] af03 sysad[43] af04 sysad[6] af05 sysad[5] af06 sysad[42] af07 sysad[47] af08 sysad[2] af09 sysad[32] af10 sysadc[4] af11 sysad[31] af12 sysad[48] af13 sysad[60] af14 sysad[61] af15 sysad[54] af16 sysad[27] af17 sysad[55] af18 sysad[59] af19 sysad[58] af20 syscmd[8] af21 syscmd[4] af22 syscmd[0] af23 sctce_ af24 serint1_ af25 outmodepll af26 ad[61] table 463: GT-96100A pinout table (continued) ball # signal name GT-96100A advanced communication controller 540 revision 1.0 figure 108:GT-96100A pinout map (top view, left side) 123456789 a req0_ gpp[14] gpp[13] gpp[6] vccpll mii1[14] mii1[10] mii1[4] mii1[3] b pad0[28] jtag[3] jtag[0] vsspll gpp[7] gpp[2] mdc mii1[13] mii1[9] c pad0[24] pad0[30] gnt0_ jtag[1] gpp[12] gpp[9] gpp[3] gpp[0] mii1[12] d pad0[17] pad0[25] pad0[29] jtag[2] jtag[4] gpp[8] gpp[5] gpp[1] mdio e irdy0_ pad0[20] pad0[23] pad0[26] pad0[31] gpp[15] gpp[10] gpp[11] gpp[4] f perr0_ frame0_ pad0[18] pad0[22] pad0[27] vss vss vcc2.5 vcc3.3 g pad0[14] devsel0_ cbe0_[2] pad0[21] idsel0 vss h pad0[10] par0 trdy0_ pad0[16] cbe0_[3] vcc2.5 j pad0[8] pad0[12] pad0[15] stop0_ pad0[19] vcc2.5 k pad0[6] pad0[9] pad0[13] cbe0_[1] lock0_ vcc3.3 l pad0[4] pad0[7] vref0 pad0[11] serr0_ m pad0[1] pad0[2] pad0[5] cbe0_[0] pad0[3] n pad0[0] tclk nc pclk0 nc 10 11 12 13 14 nc mii0[12] mii0[11] mii0[8] mii0[2] mii1[5] mii1[1] mii0[13] mii0[9] mii0[5] mii1[6] mii1[8] nc mii0[6] mii0[4] mii1[11] mii1[2] mii0[14] mii0[7] mii0[0] nc mii1[7] mii1[0] mii0[10] mii0[3] vcc3.3 vss vss vss vss vss vss vss vss vss vss vss vss p pad1[28] pclk1 clkoutpll nc pad1[29] r pad1[30] pad1[25] cbe1_[3] pad1[24] pad1[27] t pad1[31] vref1 pad1[17] idsel1 pad1[16] u pad1[26] pad1[22] pad1[23] pad1[19] perr1_ vcc3.3 v pad1[20] pad1[18] frame1_ stop1_ pad1[15] vcc3.3 w pad1[21] irdy1_ par1 cbe1_[1] cbe1_[0] vcc2.5 y cbe1_[2] devsel1_ pad1[13] pad1[14] pad1[4] vss aa trdy1_ pad1[12] pad1[11] pad1[10] pad1[0] vss vss vcc2.5 vcc2.5 ab serr1_ pad1[9] pad1[5] sysad[4] sysad[46] sysad[45] sysad[12] sysad[33] sysadc[1] ac pad1[8] pad1[1] pad1[3] gnt1_ sysad[8] sysad[39] sysad[14] sysad[44] sysadc[5] ad pad1[6] pad1[2] sysad[40] sysad[37] sysad[41] sysad[15] sysad[38] sysad[34] sysad[0] ae pad1[7] req1_ sysad[10] sysad[13] sysad[11] sysad[9] sysad[35] sysad[3] sysad[1] af sysad[36] sysad[7] sysad[43] sysad[6] sysad[5] sysad[42] sysad[47] sysad[2] sysad[32] 123456789 vss vss vss vss vss vss vss vss vss vss vss vss vcc3.3 nc sysad[62] sysad[52] nc nc sysadc[7] sysad[63] sysad[51] sysad[19] sysad[18] sysadc[3] sysadc[6] sysad[49] sysad[16] sysad[17] sysadc[0] sysadc[2] sysad[30] sysad[29] sysad[28] sysadc[4] sysad[31] sysad[48] sysad[60] sysad[61] 10 11 12 13 14 GT-96100A advanced communication controller revision 1.0 541 figure 109:GT-96100A pinout map (top view, right side) 15 16 17 18 19 20 21 mii0[1] portf[6] portf[4] portf[2] porte[5] porte[1] portd[4] nc portf[3] porte[6] porte[4] portd[5] portd[0] portc[6] portf[5] portf[1] porte[3] portd[6] nc portc[5] portc[1] portf[0] porte[2] porte[0] portd[1] portc[4] portb[6] portb[5] nc portd[2] portd[3] portc[2] portb[2] portb[3] porta[5] vdd3.3 vdd2.5 vdd2.5 vss vss vss 22 23 24 25 26 nc portc[3] portb[1] porta[4] porta[0] a portc[0] portb[0] porta[2] ready_ ad[33] b portb[4] porta[3] dmareq[0]_ ad[0] ad[2] c porta[6] ale cstiming_ ad[32] ad[37] d porta[1] bypsoe_ ad[34] ad[5] ad[9] e ad[1] ad[36] ad[4] ad[39] ad[11] f ad[35] ad[6] ad[7] ad[42] ad[13] g vdd2.5 vdd3.3 vdd3.3 vss vss vss vss vss vss vss vss vss vss ad[3] ad[8] ad[40] ad[43] adp[0] h ad[38] ad[10] ad[12] ad[45] adp[4] j ad[41] ad[44] ad[14] ad[47] sdqm[0] k ad[46] adp[1] ad[15] adp[5] sdqm[5] l dwr_ sdqm[4] scas_ sdqm[1] scs_[0] m scs_[1] dadr[0] dadr[1] sras_ nc n dadr[4] dadr[7] dadr[3] dadr[2] dadr[5] p dadr[9] scs_[2] dmareq_[2] dadr[8] dadr[6] r vss vss vdd3.3 vdd2.5 vdd2.5 vss vdd3.3 vdd3.3 vdd2.5 vss vss sysad[20] sysad[26] syscmd[1] scdoe_ interrupt1_ interrupt0_ bypasspll sysad[50] sysad[57] syscmd[7] syscmd[2] validin_ scmatch scword[0] sysad[24] sysad[22] sysad[23] syscmd[6] validout_ release_ nc sysad[25] sysad[21] sysad[53] sysad[56] syscmd[5] syscmd[3] wrrdy_ sysad[54] sysad[27] sysad[55] sysad[59] sysad[58] syscmd[8] syscmd[4] 15 16 17 18 19 20 21 ad[17] sdqm[7] dmareq_[1] nc dadr[10] t ad[48] adp[6] sdqm[3] scs_[3] dmareq_[3] u ad[53] ad[49] adp[3] sdqm[6] banksel[0] v ad[25] ad[52] ad[50] adp[7] sdqm[2] w ad[56] ad[23] ad[20] ad[18] adp[2] y ad[27] ad[55] ad[22] ad[51] ad[16] aa ad[29] ad[58] ad[24] ad[54] ad[19] ab ad[62] ad[63] ad[28] ad[26] ad[21] ac serint0_ nmi_ ad[30] ad[60] ad[57] ad scw ord[1] reset_ w de_ ad[31] ad[59] ae syscmd[0] sctce_ serint1_ outmodepll ad[61] af 22 23 24 25 26 GT-96100A advanced communication controller 542 revision 1.0 34. 492 bga p ackage m echanical i nformation figure 110:492 bga package mechanical information GT-96100A advanced communication controller revision 1.0 543 35. GT-96100A p art n umbering figure 111:sample part number 35.1 standard part number the standard part number for the GT-96100A is: GT-96100A?b?x. without the ?xyyy?zz suffix, this part number indicates that it is the commercial temperature grade, 100mhz version. in other words, GT-96100A-b-x is the same as GT-96100A?b?x?c100?00, although it is not marked with the suffix information. 35.2 valid part numbers the following part numbers are the only valid part numbers that can be used when ordering the GT-96100A: ? GT-96100A?b?x, commercial temperature, 100mhz ? GT-96100A?b?x?c083?00, commercial temperature, 83mhz gt?96100a?b?x?c083?00 device prefix gt part number 96100a package type b = bga revision/stepping number 0 = initial silicon 1 = 1st revision/stepping 2 = 2nd revision/stepping etc. temperature range c = commercial i = industrial speed 083 = 83 mhz 100 = 100 mhz 00 = standard device GT-96100A advanced communication controller 544 revision 1.0 36. a bbreviations bbit bbyte gbps gigabits per second khz kilohertz ma milliampere mhz megahertz ns nanosecond vvolt gb gigabytes gb gigabits kb kilobytes kb kilobits mb megabytes mb megabits GT-96100A advanced communication controller revision 1.0 545 37. r evision h istory table 464: document history document type rev. number date comments product preview 0.1 april 17, 2000 preliminary release datasheet 1.0 3 october, 2000 1. in table 107 , "sdram burst mode ", the following changes were made: bit 10 & bit 11; initial value changed from 0x1 to 0x0. bits 31:12; initial value changed from 0x1 to x. 2. in table 281 ?hash table entry fields" , the following changes were made: bits 52:51was added. bits 63:51 changed to bits 63:53. 3. in table 463 ?gt?96100a pinout table" , the following changes were made: ad21 changed from vss to nc. the note at the end of the table was modified. 4. in the features section 83mhz for cpu frequency support was changed to 100mhz. 5. in section 13.7.4 ?transmit sdma notes? on page 317 , information added. 6. in table 270 ?pci_0 arbiter configuration register, offset: 0x101ae0" , a note was added in priority arbitra- tion enable field 7. in section 12.1 ?functional overview? on page 253 , added information. 8. in table 14 ?interrupt interface pin assignments" , the following changes were made: sor section deleted. gpp is defined as 15:0, no reserved bits. interrupt1* notation as sor type was deleted. 9. in table 181 ?pci_1 scs[1:0]* base address, offset: 0x090 from pci_0 or cpu; 0x010 from pci_1" , initial value changed to 0x08 from 0x04. 10. table 183 ?pci_1 scs[3:2]* base address, offset: 0x094 from pci_0 or cpu; 0x014 from pci_1" , initial value changed to 0x01000008 from 0x01000004. 11. in table 375 , table 376 , table 377 and table 378 , gpp changed to 15:0. 12. in table 200 ?pci_1 pmc register, offset: 0x0c0 from pci_0 or cpu, 0x040 from pci_11" , initial value changed to 0x00090001 from 0x91. GT-96100A advanced communication controller 546 revision 1.0 datasheet 1.0 3 october, 2000 13. table 204 ?function 1 pci_1 swapped scs[1:0]* base address, offset: 0x190 from pci_0 or cpu; 0x110 from pci_1" , initial value changed to 0x08 from 0x04. 14. table 206 ?function 1 pci_1 swapped scs[3:2]* base address, offset: 0x194 from pci_0 or cpu; 0x114 from pci_1" , initial value changed to 0x01000008 from 0x01000004. 15. in section 32. ?ac timing? on page 513 , the following changes were made: rst* changed to reset**. "10 tclk cycle" to "0.5 msec". 16. table 415 , table 416 and table 417 were changed as follows: "...the value latched in the gpd register bit is '1'" changed to "...the value latched in the gpd register bit is '0'. 17. in table 292 ?serial parameters register (spr), offset: 0x084820 for ethernet_0; 0x088820 for ethernet_1" , the following changes were made: initial value changed to "11001 (64 bit time)" from "10000 (64 bit time). the function description was modified. 18. section 31.1.1 ?power sequencing notes? on page 510 was added. 19. section table 327: ?chxr1 - sync/abort register (synr), offset: 0x000a0c, 0x008a0c, 0x010a0c, 0x018a0c, 0x020a0c, 0x028a0c, 0x030a0c, 0x038a0c (where x is channel 0 to 7)? on page 342 was modi- fied. 20. in section 14.1.3 ?receive dpll clock recovery? on page 328 , the text was modified. 21. in section 14.7.1.1 ?asynchronous mode? on page 361 , "the dpll sampling rate" changed to "the dpll encoding must be set to nrz and the clock ampling rate". 22. in table 6 ?pci bus 0 pin assignments" , the following changes were made: ? "req0*/parb0_gnt0" changed to "req0*/parb0_gnt1" ? "pci_0 arbiter output grant 0" changed to "pci_0 arbiter output grant 1" ? "functions as the arbiter's grant 0 output" changed to "functions as the arbiter's grant 1 output" ? "gnt0*/parb0_req0" changed to "gnt0*/parb0_req1" ? "pci_0 arbiter input request 0" changed to "pci_0 arbiter input request 1" ? "functions as the arbiter's request 0 input" changed to "functions as the arbiter's request 1 input". 23. in table 7 ?pci bus 1 pin assignments" , the following changes were made: ? "req1*/parb1_gnt0" changed to "req1*/parb1_gnt1" ? "pci_1 arbiter output grant 0" changed to "pci_1 arbiter output grant 1" ? "functions as the arbiter's grant 0 output" changed to "functions as the arbiter's grant 1 output" ? "gnt1*/parb1_req0" changed to "gnt1*/parb1_req1" ? "pci_1 arbiter input request 0" changed to "pci_1 arbiter input request 1" ? "functions as the arbiter's request 0 input" changed to "functions as the arbiter's request 1 input". table 464: document history (continued) document type rev. number date comments GT-96100A advanced communication controller revision 1.0 547 datasheet 1.0 3 october, 2000 24. in table 11 ?wan pin assignments" , the following changes were made: ? "parb0_gnt1" changed to "parb0_gnt2" ? "pci_0 arbiter output grant 1" changed to "pci_0 arbiter output grant 2" ? "parb0_req1" changed to "parb0_req2" ? "pci_0 arbiter input request 1" changed to "pci_0 arbiter input request 2" ? "parb0_req2" changed to "parb0_req3" ? "pci_0 arbiter input request 2" changed to "pci_0 arbiter input request 3" ? "parb0_gnt2" changed to "parb0_gnt3" ? "pci_0 arbiter output grant 2" changed to "pci_0 arbiter output grant 3" ? "parb0_gnt3" changed to "parb0_gnt4" ? "pci_0 arbiter output grant 3" changed to "pci_0 arbiter output grant 4" ? "parb0_req3" changed to "parb0_req4" ? "pci_0 arbiter input request 3" changed to "pci_0 arbiter input request 4" ? "parb0_req4" changed to "parb0_req5" ? "pci_0 arbiter input request 4" changed to "pci_0 arbiter input request 5" ? "parb1_gnt1" changed to "parb1_gnt2" ? "pci_1 arbiter output grant 1" changed to "pci_1 arbiter output grant 2" ? "parb1_req1" changed to "parb1_req2" ? "pci_1 arbiter input request 1" changed to "pci_1 arbiter input request 2" ? "parb1_req2" changed to "parb1_req3" ? "pci_1 arbiter input request 2" changed to "pci_1 arbiter input request 3" ? "parb1_gnt2" changed to "parb1_gnt3" ? "pci_1 arbiter output grant 2" changed to "pci_1 arbiter output grant 3" ? "parb0_gnt5" changed to "parb0_gnt6" ? "pci_0 arbiter output grant 5" changed to "pci_0 arbiter output grant 6" ? "parb1_gnt3" changed to "parb1_gnt4" ? "pci_1 arbiter output grant 3" changed to "pci_1 arbiter output grant 4" ? "parb0_req5" changed to "parb0_req6" ? "pci_0 arbiter input request 5" changed to "pci_0 arbiter input request 6" ? "parb1_req3" changed to "parb1_req4" ? "pci_1 arbiter input request 3" changed to "pci_1 arbiter input request 4" ? "parb0_gnt4" changed to "parb0_gnt5" ? "pci_0 arbiter output grant 4" changed to "pci_0 arbiter output grant 5" 25. in table 270 ?pci_0 arbiter configuration register, offset: 0x101ae0" , the following changes were made: parb0_g5, parb0_r5 changed to parb0_gnt1,parb0_req1 "0 - this pin to function as all psclk1." changed to "0 - this pin to function as otslkc1." table 464: document history (continued) document type rev. number date comments GT-96100A advanced communication controller 548 revision 1.0 datasheet 1.0 3 october, 2000 26. in table 271 ?pci_1 arbiter configuration register, offset: 0x101ae4" , "(execpt for bit 29 is reserved)" changed to "(execpt for bits 30:29 which are reserved)." 27. in table 16 ?test interface pin assignments" , the following changes were made: jtag[2] type changed from "o" to "i" jtag[3] type changed from "i" to "o". 28. in table 463 ?gt?96100a pinout table" , ad21 signal name changed from "vss" to "nc". 29. in section 12.4.1.5 ?backoff algorithm options? on page 277 , "port_configuration_extend GT-96100A advanced communication controller revision 1.0 549 datasheet 1.0 3 october, 2000 36. in table 458 ?mpsc transmit timing" , the following changes were made: t71 & t72 max value were removed. t73 max value changed from 10 to 13. t75 min value changed from 8 to 5. 37. new section 36, abbreviations was added. 38. in section 5.11.1 ?sdram and device address decode? on page 130 , table 86 through to table103 were changed as follows: bits 7:0 changed to 11:0 and bits 31:8 were changed to 31:12. 39. section 4.8.2 ?multigt bit in the cpu configuration register? on page 82 was modified. 40. section 4.8.4 ?multi-gt restrictions? on page 83 was modified. 41. in table 36 ?cpu interface configuration, offset: 0x000" , the following changes were made: pins 8:0 & 9 & 10 were changed to "reserved (must be zero)". description added to endianess "note: affects only the internal registers, and the pci configuration data reg- ister". 42. figure 44 modified. 43. in table 17 , pin outmodepll description modified to "...pin is in hi-z state." 44. in table 316 the following changes were made: the initial value for bits 5:2 was changed to ?1111?. 45. in table 172 , the initia value was changed from 0x9652 to 0x9653. 46. in table 173 , the initia value was changed from 0x965211ab to 0x965311ab. 47. in table 173 , the initia value was changed from 0x02ab to 0x03. 48. table table 403 . the title was corrrected from ? ethernet1 cause register...? to ?ethernet1 mask reg- ister...?. 49. table 449 ?thermal data for GT-96100A in bga 492" was modified. table 464: document history (continued) document type rev. number date comments |
Price & Availability of GT-96100A
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |